[darkf]

>lambda is fine, if you're writing in functional style you're using expressions for everything anyway.

No, I /really would/ like to be able to write:

foo.on_click(lambda: x += 1)

The language not supporting this (when most others do) is just silly.

[amyjess]

> foo.on_click(lambda: x += 1)

Mutation in lambdas is not compatible with your complaint about "inadequate support for high-level functional programming", as it goes against the principles of FP.

You can't do that in Haskell either, and any FP purist would blanch at a statement like that.

[codygman]

> You can't do that in Haskell either, and any FP purist

What about us FP pragmatists? Also in some domains I'd argue being a FP purist is the most pragmatic option.

[darkf]

>You can't do that in Haskell either, and any FP purist would blanch at a statement like that.

Obviously you've never met State and/or lens then.

Yes, you can do it -- and no, I never said it should follow pure FP principles.

[lmm]

But if you write a State equivalent of "x += 1" in Python then you can use it in a lambda too.

[kazinator]

Are you saying that a non-mutating variant of the above works? For instance:

   foo.on_click(lambda:x func(x, whatever))

[dragonwriter]

yeah, except that the syntax is

  lambda x: func(x, whatever)

In fact, if x is an object that stores a mutable numeric cell, you could even do a mutating:

  lambda x: x.add(1)

Mutation isn't prohibited in Python lambdas, statements (including assignments, which are statements rather than expressions in Python), however, are.

[BeetleB]

It is amusing your lambda usage could be used by the Python community as a classic example of problems that can occur if they allowed what you want.

Mutating variables in a lambda is something abhorred in many functional languages.

[mundanevoice]

Try using some other language that is functional like LISP or Haskell maybe. Python goals is not be a functional language that that's okay.

[lmm]

That seems like an exceedingly error-prone thing to write. "x +=1" isn't a value and the unmanaged mutation will be surprising when it happens. On a Python implementation with parallelism (e.g. Jython) you could very easily end up losing updates - on CPython the GIL will probably mean your code accidentally doesn't exhibit that problem, but that doesn't seem a very desirable way to code.

[jononor]

What is the proposed alternative? (using a named function or method just seems to be semantically the same, just more characters)

[lmm]

Something like functional reactive programming style, where you explicitly define a pipeline from foo.click to x and explicitly gather together all your pipelines (explicitly defining the interleaving semantics rather than just "whenever an event happens it happens") and run them in one place.

[xapata]

    foo.on_click(partial(q.append, foo))

The nice thing about ``append`` is it's atomic (for builtins).

[jononor]

Where does the update of `x` go in this example? By observing a Queue or Stream `q`?

[xapata]

If it must be mutable state, then ideally you'd have a single consumer thread for counting off that queue to avoid worrying about locks.

Or maybe what's in the queue gets written to a permanent log and ``x`` is a query of that log, a la Datomic.

[mst]

Huh. In perl (and javascript) x += 1 is an expression that returns the new value of x.

I guess this is another "simplification" along with the magic scoping model (I want perl's my/ES6's let damnit sulk) ...

[lmm]

x += 1 should be a statement rather than an expression. It's not just a value, evaluating it has an effect.