[jerf]

(The Internet being what this is, this comment is NOT criticism... it's elaboration and explanation.)

So part of what makes this so clean is that this is the "list monad" implementation, and nothing else at all. This is a perfectly fine implementation of the specific "monad", but there's no abstraction between the specific list implementation and the generic monad machinery.

This probably helps more clearly see what's going on with the list monad (arguably the simplest monad implementation that is also non-trivial and slightly hard to follow when you start mixing it with guards and such), but it will get a bit nastier when you factor out the monad machinery and have to invoke it too. Python also gets nastier when you can't fit everything into a lambda because of its restrictions. Plus once you have to put a "def" in the middle, it "pollutes" its way back up the stack, because in order for the closure to work properly it has to be defined inline (inner functions should have access to the outer scope's variables), which means everything above it has to be turned into a full function too.

So, on the one hand it is fair to point out this solution does work and isn't impossibly nasty to look at, but, on the other hand, it isn't generic and it will also tend to break down in practice for Python. Perl's actually comes out slightly nicer since the subroutines are indeed full subroutines so you don't have the lambda limitations to work with, but still impractically complicated if you try to abstract out the "monad" machinery.

[sadgit]

This topic is amusing - the question of why you would want to do this has never come up, it is truly just art and playfulness.