Not shown in this article are all the things you can do within the [] (typically just [&] or [=]), which turns a simple lambda into a closure.

The syntax is a bit arcane, but it does what it needs to. They could've stuck a "lambda" keyword in front of it all, but it's not necessary, and making a new keyword always has the potential to break old code.

is it possible to do

#define lambda []

?

I think that's possible, but I would strangle anyone who actually did that. At that point, not only are you pointlessly redefining the language just so it can feel slightly more familiar to people who are more comfortable with Python and the like, but you also completely lose the ability to enclose variables in the square brackets to make a closure.

If you're going to write C++, then write C++. Don't redefine language constructs to fit the patterns of your other favourite language.

I think you can

  #define begin {
  #define end   }

too. I would not suggest it though.

That way lies http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/...

Backwards compatability. Old valid code should remain valid. That includes code which calculates wavelengths.

An interesting example of C++ not being able to introduce new keywords is the co-opting of auto in C++11 from a storage class to type deduction.

But they had a decent justification: the auto keyword literally did nothing in C++. The only place it was valid, it was also the default.

IIRC they audited a bunch of projects to see if anyone was using auto somewhere besides test code explicitly for the auto-keyword, and found nothing.

I don't like that in python you are enforced to only use a single expression in lambda. Sure, writing long lambda functions is ugly but I don't think python should enforce a given coding style in the language level.

Isn't that literally a core principal of Python? They enforce all kind of coding styles within the language, not the mention all the PEPs.

But PEPs are not enforced in the language level. Also there are cases where there could fit two simple expression in a lambda. Also the language still doesn't stop you from abusing lambdas, you can nest them. It could be stated in one of the PEPs that "no overly complicated lambdas" and that's it, there is no need for the language to enforce this.

PEPs are literally the language, in my opinion. It may not be enforced on an implementation level, but some have been. You can't mix spaces and tabs now. That seems like a style choice being enforced on every level.

While I see the use for multi-statement lambdas, and I use them all the time in {Java,Coffee}Script, they are rarely needed in Python as there is always a more idiomatic way to write the code. In particular, with for loops and generator expressions (~list comprehensions) you can cover almost all uses of .each, .map, .filter, .some (`any` in Python), .every (`all` in Python), etc.

That also dramatically reduces the value of lambdas. Without that limitation then they work as anonymous blocks of any complexity.