[Python-ideas] Thoughts on lambda expressions

[Terry Reedy]

On 3/2/2016 10:48 PM, Nick Coghlan wrote:

> I'm personally not averse to adding new syntactic sugar for lambda
> expressions, but if we did do something like that, I'd advocate for
> just stealing Java's spelling (perhaps with the addition of mandatory
> parentheses, ala generator expressions):
> https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#syntax
>
> The rationale for that would be:
>
> 1. "(params -> expr)" is easier on the eyes than "lambda params: expr"
> 2. "->" is already used to separate function parameter definitions
> from the return type annotation
> 3. It makes moving back and forth between Java & Python easier
> 4. Swift uses '->' to separate the parameter type and return type
> declarations in closure expressions [1]
> 5. It's also similar to the C# lambda expression syntax (which uses
> "=>" rather than "->") [2]
> 6. JavaScript ES6 also has an "arrow function" construct similar to
> the C# lambda expression [3]

Not bad.

7. It is similar to the pattern matching expressions used in ml and 
probably elsewhere.

fac:
   0 -> 1
   n -> n * fac(n-1)

Of course as a lambda substitute, only one (generic) pattern is allowed 
and no recursion (absent the use of combinators, but ignore that).

> While that may sound like an "argument from popularity" (and there are
> certainly aspects of that), my main rationale for advocating for
> consistency with other popular (or operating system vendor backed)
> languages with similar capabilities would be to *increase Python's
> value as a teaching language*: making semantically similar constructs
> look similar to the way they look elsewhere makes it easier for folks
> that start their text-based programming education with Python to later
> make the move to a different platform (if that's where their career
> and interests takes them), and "helps in preparation for other
> environments" is a positive characteristic in a world where developers
> are spoiled for choice when it comes to programming languages and
> runtimes.
>
> However, I'm not interested enough in the idea to propose it myself -
> I'm interested in the problem from an abstract language design
> perspective these days, not a "this actually bothers me personally"
> sense [4].
>
> [1] https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Expressions.html
> [2] https://msdn.microsoft.com/en-AU/library/bb397687.aspx
> [3] https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions
> [4] That wasn't always true, as can be seen if you search far enough
> back in the dev list archives :)

-- 
Terry Jan Reedy