Hacker News new | past | comments | ask | show | jobs | submit login

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




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: