A bit sad that this stopped working in lambdas in Python 3, it was nice to have in Python 2:

    (lambda (x, y): x+y)((2, 3),)

That's pretty cool, shame it doesn't work in 3 too.

Not as nice, but:

    (lambda x, y: x+y)(*(2, 3))
Seems to work

Now do

  lambda i,(x,y): x[i]+y[j]
I never really understood the rationale here. Pep8 hates lambdas, which is also baffling. It seems as though tptb don't like lambdas, but there wasn't enough political will to remove them entirely, so they kneecapped them instead. Because... more lines = more readable??

But we've got a walrus operator now, because... less lines = more readable?

You golf a lambda and then deride walrus in the same comment? Please explain yourself.

And if you really want to make the perfect lambda, you can do that with code generation and frame walking/patching.

http://farmdev.com/src/secrets/framehack/index.html

That wasn't golf. Are you going to tell me that this is more legible?

   lambda i, t: t[0][i] + t[1][i]
edit: and... that frame hack thing is fun, but what does it have to do with anything?

Also, note that I don't "deride" the walrus operator. But it does smack of inconsistency. Are we aiming for clean notation or not?

You want tuple params back into an inlined function declaration? You can do that with a framehack. One of the examples from the link is Ruby style string interpolation, f-strings in Python, before f-string support.

You can fight Python on lambda support, or you can build the language you want. It gives you the tools.

I am not arguing about lambda legibility, but tilting at windmills rather than just walking around them. They can't move.

Do you really use framehacks in production for the sake of syntactic sugar like this? It's fair that Python can do this sort of thing[0], but it seems like begging for trouble to make it load-bearing without a very strong reason.

[0] That level of access was essential when I was working on https://codewords.recurse.com/issues/seven/dragon-taming-wit...

If the local sugar leads to a lower incidence of diabetes, then yes.

I have never had a framehack spontaneously break. Self proclaimed Pythonistas of course make a sour face, like their God was offended, but that isn't a logical argument against.

I really enjoy your compiler art, please keep it up. Are you doing anything with Wasm these days?

Thank you!

I dislike style nazis too, e.g. carping when Peter Norvig's code won't pass PEP 8.

I'm just leery of the expected cost in this kind of case. It can go on working for years until some new complication or some change in the ecosystem makes it suddenly create a really weird problem. Or when you want to try moving to a fancy new Python implementation, you find you have this friction. Matter of judgement where some chance of such messes is paid for by what it can do for you. (Of course when it's less "load bearing" the balance shifts.) With https://coverage.readthedocs.io/en/stable/ for example, it used bytecode hacks to do something you couldn't do otherwise, and that's unlikely to mess you up.

I have had old C programs go crazy years later in a really hard to debug way because newer compilers may interpret your code like your ex-wife's divorce lawyer (as Kragen put it). Back in the day a lot of us thought we had a different kind of relationship with C compilers, and it'd be fine to code to that informal social contract. (Just a loose analogy.)

I'm piddling away at https://github.com/darius/cant these days. (Some of the motivation was feeling too confined by Python, actually.) No Wasm, but I'm happy it exists! I tried to make a system like it 20 years ago (Idel) and gave up too soon.

I love E! Or at least the problems it is trying to solve. As you know Wasm also has a capabilities model. And it is fairly trivial to persist the Wasm heap, it just an array of bytes. I think Wasm aligns nicely.

Chez is a great Scheme, but it doesn't have a Wasm backend. I find https://github.com/schism-lang/schism very interesting.

As for C programs going crazy, well yeah. I did a thing where I would copy of the body of functions around in memory, it worked on some version of Linux and GCC, but only by accident. I would be much less comfortable doing this kind of circuit bending than modifying Python stack frames. If I were to achieve a similar goal in the future, I'd use TCC, generate C code and compile directly into memory.

Framehacks aren't going to do the same thing, and one should have tests for it regardless. Framehacks get you tail calls, stack scope and a bunch of other nice properties.

Happy Hacking!