Hacker News Reader

Hacker News

Comment by darkf | Hacker News Reader

Parent Full thread

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.

View on HN

> 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.

>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.

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

> 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.

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

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

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.

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.

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.

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.

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

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.

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

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

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

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.

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) ...

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

Reply on news.ycombinator.com