[Stephen Turnbull] > I was an economist then, and I'm an economist still, but I met lambda > in 1977. Surely lambda has had that role in computer languages since > shortly before I was born.
According to Wikipedia <https://en.wikipedia.org/wiki/Anonymous_function> Lisp was the first language to use anonymous functions (introduced in 1958). [Stephen Turnbull] > I would guess anybody above a certain age > would reach for "lambda" first for a keyword to denote or define an > anonymous function. Not because of the lambda calculus, but because > of Lisp. Wikipedia lists the anonymous function syntax of 40+ languages <https://en.wikipedia.org/wiki/Anonymous_function#Examples> and only 5 (Lisp, Scheme, Python, Ruby, and Maxima) use the "lambda" keyword. Haskel uses a "\" which I'm pretty sure is supposed to look like the lambda symbol, but even that syntax seems unpopular too. [Stephen Turnbull] > Maybe there's a better word than "regret". After all, It's > hard to see how you could prototype range better than "range([START,] > END, [STRIDE])", and the same might be true for "def [NAME] ([ARG0,] > ...):". I wasn't aware that Guido considered "range" to be warty. I like the way it mimics slicing syntax. It makes it easy for me to remember. It seems like a very pragmatic design. [Steven D'Aprano] > Secure in the knowledge that Guido probably isn't reading this and won't > contradict me *wink* I'm going to try channelling him. SUMMON THE GREAT CREATOR! I wonder if I say his name three times... Guido Van Rossum! Guido Van Rossum! Guido Van Rossum! [Steven D'Aprano] > I think he would regret "def expressions", but not because of the range > reason. I think its because he likes the relatively strict demarcation between statements > and expressions. > We have 4 statements that have a expression form: > if...else versus ternary if expressions; > for loops versus comprehensions; > (soon) = assignment versus := assignment expressions; and > def versus lambda. (I don't know why Gmail's quotes screw up formatting...) I don't think that's the reason those expressions have different formats than their statement counterparts. Expressions allow for more flexible arrangement than expressions because the order of execution of an expression doesn't have to follow the order of declaration. While it's more natural to say "do something to each item in this collection that meets some condition" you can't access variables before they're declared in statements so you have to tell the computer explicitly that you're looping over some iterable first. Expressions allow you to be more expressive. You don't have to put your edge-case checking up-front and in the way. When 99.9% of the time you just want: x = y you can shove the edge-case checking to the side and let the core logic shine: x = y if not edge_case else special_value # extra spaces added for emphasis besides: result = if condition expression else expression is super awkward to read out loud. That's not how I think at least. I've never hears someone say, "My child's name will be if it's a girl Sally otherwise Billy." All of the expressions use either the same or similar keywords or symbols *except* def and lambda. func = def <args>: <expression> Is about as different from the statement form as "x := y" is from "x = y". No name, no parentheses for the arguments. Finally, I know you've heard the other half of my anti-lambda manifest, but I don't know if Stephen Turnbull has, so I'll briefly present it again. It's not just the name "lambda" that bothers me, it's the arrangement of the logic and signature. I believe that the expressiveness that allows comprehensions to put the core logic in front of the less important (for readability) loop and filtering constructs, anonymous functions could have been arranged to put the logic in front of the (almost always) less important signature. The reason I say the signature is almost always less important is because one almost always uses an anonymous functions as an argument (key-function, callback, map, reduce, filter, etc.) to something that already defines the call signature it expects. Consider the alternate form: <expression> with <args> (thought there are many alternative possibilities) hand = sorted(cards, key=lambda card: value[card.suit] if card is not wild else max_value) hand = sorted(cards, by=value[card.suit] if card is not wild else max_value with card) # notice how unsurprising it is that the signature is "card" Oh wait... Did I accidentally replace "key" with "by"? Huh... It seems to make more sense even though the jargon is a "key function"... Oops! ;) Note: if this were a full proposal, lambdas with complex arguments or in certain situations would require parens: (<expression> with <args>) On Tue, Aug 21, 2018 at 9:31 AM, Steven D'Aprano <st...@pearwood.info> wrote: > On Tue, Aug 21, 2018 at 02:07:33PM +0900, Stephen J. Turnbull wrote: > > > I was an economist then, and I'm an economist still, but I met lambda > > in 1977. Surely lambda has had that role in computer languages since > > shortly before I was born. I would guess anybody above a certain age > > would reach for "lambda" first for a keyword to denote or define an > > anonymous function. Not because of the lambda calculus, but because > > of Lisp. (OK, that's indirectly because of the lambda calculus.) > > Its pretty much a term of art. > > (Aside: "term of art" is itself a term of art: > https://legal-dictionary.thefreedictionary.com/Term+of+Art ) > > > I think that complaining about lambda is like complaining about "3-sigma > versus 6-sigma processes" in process management. (Not computer > processes, manufacturing processes and quality control.) Or for that > matter, "mean" and "standard deviation" in statistics. > > The main difference is that most people are introduced to mean and stdev > in secondary school, while functional programming idioms and lambda are > generally stumbled across in the field. (I know that's how I learned of > the term: through Python.) > > > > Had Guido decided to change it to "def", I suspect he'd be regretting > > it slightly today, for reasons similar to the regrets about "range": > > we normally only allow omitting positional arguments at the end of the > > list. Maybe there's a better word than "regret". After all, It's > > hard to see how you could prototype range better than "range([START,] > > END, [STRIDE])", and the same might be true for "def [NAME] ([ARG0,] > > ...):". > > Secure in the knowledge that Guido probably isn't reading this and won't > contradict me *wink* I'm going to try channelling him. I think he would > regret "def expressions", but not because of the range reason. I think > its because he likes the relatively strict demarcation between > statements and expressions. > > We have 4 statements that have a expression form: > > if...else versus ternary if expressions; > > for loops versus comprehensions; > > (soon) = assignment versus := assignment expressions; and > > def versus lambda. > > (Did I miss any? I don't include technicalities like dot attribute > access versus getattr and similar.) It's notable that in none of those > cases the syntax is quite the same in the two forms. There's always > enough differentiation between the statement and expression that there's > never any ambiguity which is intended. We don't have: > > result = if condition expression else expression > > where it is the lack of colons which hints that it is an expression, we > have a completely different syntax. So I think Guido probably wouldn't > like the idea of using def in expressions: > > def function(arg, callback=def: None): > pass > > > That's my guess, for what it's worth. > > > > -- > Steve > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
