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:
>
> http://www.rosettacode.org/wiki/Function_definition
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.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/UQXNFG37QLNGPKXSBVBTSC7SEF5H7ORT/
Code of Conduct: http://python.org/psf/codeofconduct/
