Comment by halo | Hacker News Reader

Comment by halo | Hacker News Reader

Parent Full thread

The reason no other language does that is because no other mainstream language uses newline and indentation to indicate blocks, which makes all general-purpose multi-line anonymous function syntaxes inherently ugly and non-Pythonic: where should the new block's indentation begin or end? I also regard it as a relatively minor problem as there's little cognitive overhead from simply naming a multi-line function, and I can see advantages in encouraging naming for complex functions.

Having thought about it for a couple of hours, I don't think there is any good solution for adding multi-line anonymous functions to Python. The suggested syntax feels non-Pythonic, is inherently unexpressive and difficult to read, only useful in a few select use-cases while not solving the holy grail of 'pleasant anonymous functions', and the single problem it's solving isn't common enough or big enough to need dedicated syntax and could already largely be solved with a named function. The fact it enables 'misuse' via Ruby-style iteration, going against Pythonic ideals of 'one way to do things', doesn't work in its favour either.

I don't think analogies with decorators are good either. The advantages of decorators is they transform something otherwise difficult-to-read and unexpressive into something easier-to-read and more expressive, whereas this makes something that's easy-to-read less expressive with the only advantage being terseness. Python, unlike other languages, focuses primarily on clarity over code length.

The reason no other language does that is because no other mainstream language uses newline and indentation to indicate blocks, which makes all general-purpose multi-line anonymous function syntaxes inherently ugly

Haskell is newline-and-indentation-based and allows multi-line anonymous functions.

With that in mind, I often prefer to name functions, but not let them be globally callable, i.e.

    f = (g . h) where
        g = (2*)
        h = (1+)

Does Python allow something like this? (Equivalents in other languages:

    (defun f (x) 
      (flet ((g (x) (* 2 x))
             (h (x) (1+ x)))
        (g (h x))))

Or:

    sub f {
        my $g = sub { 2 * $_[0] };
        my $h = sub { 1 + $_[0] };
        return $g->($h->($_[0]));
    }

I think Haskell is prettiest, but this is not a concept unique to Haskell, and it's a technique I find useful in all three languges.)

Yeah, Python has named local functions:

  def f(x):
    def g(x): return 2 * x
    def h(x): return 1 + x
    return g(h(x))

More interesting was your point that Haskell has anonymous functions and is whitespace delimited. I don't think significant whitespace and anonymous functions have any connection at all.

It's a big deal. The holy grail here is "nice general-purpose closure syntax". So the first try is the obvious:

  function_name(
  def(e):
    print e
  def(f):
    print f
  )

Now, this isn't inherently terrible and quite easy to read (although could very easily end up in debugging hell), but the problems begin because really you'd also have to allow this:

  function_name(def(e):
    print "e", def(e):
    print "f"
  )

Which is _really_ ugly, especially as you can't indent it more as it's against Python's (sane) indentation semantics. So this is ruled out.

Then you end up with Haskell-style:

  function_blah(e, f) where:
    e = lambda e: print e
    f = lambda f: print f

This has multiple disadvantages for few advantages. Things go from "top-down" to magically changing form to what's underneath changes the statement above. This is suicide in an imperative language, least of all Python. And jumping from lambda to lambda isn't particularly readable either. And you still have to name your lambdas. The current syntax is better.

There is the alternative

  within blah def e(e):
    print e
  blah(e)

but this creates messiness where you define a function for blah before blah is defined, which is messy. And you still need a name. And you could accidentally whack out other variable names.

So Python's blocks prevent you doing nice multi-line anonymous functions.

So your only choice is to create a special-case solution, as suggested in this post. So you end up thinking:

  using blah do (e):
    print "e"

Which only passes one. Now, this is less versatile than the other solutions, only allows you to pass a single parameter or anonymous function in, and is less readable - it's simply not /obvious/ what this does unless you know beforehand.

I see your point about the bad interaction between indentation-based block delimitation and parens for function parameter delimitation.

But I think something like Ruby's block syntax should be doable, and probably you can even pass multiple blocks, with some limitations on which parameters can receive them. Here's another shot at it, just for fun: http://codepad.org/mVigj978

Arguably it's not a multi-line anonymous function, but several statement-level 'named variables' rather than block-level 'named variables'. Haskell doesn't really have the concept of "blocks" to begin with as it isn't an imperative language, so it's not really a fair comparison.

The Haskell solution is very similar to how Python currently deals with this situation, similar to your Perl and Lisp examples, by allowing named local functions within a block (rather than at statement-level), and also allowing a syntax for single-line anonymous functions (via "lambda").

I did actually ponder a Haskell-like syntax for Python, but decided it's less than ideal. Allowing assignment after a statement makes things more difficult to read, especially in imperative languages.

Reply on news.ycombinator.com