On Sat, Feb 13, 2021, at 21:57, Steven D'Aprano wrote:
# Erlang multiply(X,Y) -> X * Y.
For the record, Erlang's lambda syntax is the relatively unpleasant "fun(X,Y) -> X * Y end". Elixir is the same, except that the keyword is fn.
Dart uses "=>"
multiply(x, y) => x * y;
And Dart has a very C#-like (x, y) => x * y for lambdas, though a lot of material describing Dart's function syntax options seems to have some confusion about what a lambda is, with some describing the above ordinary function definition as a lambda, and some forgetting to explain it, only bothering to mention => for ordinary definitions and (x, y) { return x * y; } for lambdas.
More examples here:
That page doesn't really do well at explaining lambda expressions specifically, omitting it for some languages that definitely have them [such as Dart]. https://rosettacode.org/wiki/Higher-order_functions and https://rosettacode.org/wiki/First-class_functions both show examples of lambda syntax for some languages that it's missing from in the "Function definition" page... It's hard to sort through those from the ones that *don't* have a lambda syntax [compact or otherwise], since that's not the point of *any* of these pages though. https://en.wikipedia.org/wiki/Anonymous_function may be better. C# uses =>, same as Javascript, as does Scala, as does D - and like I said earlier, Java (and Kotlin, and as you mentioned Julia) uses essentially the same syntax but with ->. Anyway, Javascript started using this syntax in *2015*, C# did in *2007* [you may find some references that seem to say 2015 if not read closely, but these are discussing the introduction of => syntax to ordinary non-lambda function definitions]. In case that helps with some of the attitudes I'm seeing that this is in some way a Javascript thing that would somehow contaminate Python. I don't really buy that anyone wouldn't understand what passing "x=>x+1" as an argument means if they understand the concept of first-class functions generally. And if they don't, that difficulty isn't really syntactic. To add a few more examples to the language survey you seem to have started Go uses func(x, y) x * y Swift uses {x, y in return x * y} Rust uses |x, y| x * y, as does Ruby I still think arrows are the clear winner. I think they're intuitive, and I think that's *why* C# chose them and why other languages like Javascript copy them. It wouldn't be the first syntactic feature we'd have copied from C#.
- how many people coming to Python will be familiar with Javascript as opposed to R, Julia, Maple, etc, or no language at all?
I don't really understand why you're bringing up R/Julia/Maple specifically. Are you advocating for ->? I have no particular objection to that, but I don't think the difference between two slightly different looking arrows [one used in C#, Javascript, Scala, and D; the other used in Java, Kotlin, Julia, R, and Maple] is particularly difficult. I think either one is just as good as the other in terms of the meaning being intuitive when reading code.
- given how many other things they will have to learn that is different, is one comparatively rarely used feature more that much of a burden?
It's not about being the same to make it easier for people coming from a particular language. It's being the same because C# (and Javascript) gets it right, and we should get it right. *semi-wink* [and it being a "comparatively rarely used feature" is a bit of a circular argument - there's a case to be made that it's less used than it could be because the current syntax is cumbersome]
b) Python already uses "->" for function return *type*. And there's idea to generalize it to *function type* in general. E.g. a function "(a, b) => a + b" can have type "(int, int) -> int".
This supports the idea of using "->" as the "return operator".
Guido thinks it opposes it. I don't know if it makes much of a difference either way - people who wish to use annotations can use a full function definition. I don't think these should support annotations anyway, and I suspect they would mostly be used in contexts where annotations are unnecessary, such as as an argument to a function where the whole type of the function is already annotated.