[swift-evolution] Lambda function syntax

[Chris Lattner]

Yes, please do.  It is perfectly fine to disagree on technical points, but please do so with respect.

-Chris

> On Dec 27, 2015, at 3:44 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Please treat your fellow contributors with respect and equanimity.
> 
> Best,
> Austin
> 
>> On Dec 27, 2015, at 3:38 PM, Alexander Regueiro via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Then you clear know nothing of the history of computer science. I repeat, the original syntax of the lambda calculus, to which you were referring, was *not* designed for readability. Its purpose was entirely different. This is only the start of the differences – there really isn’t anything to be gained by comparing Swift with it – the differences in aim, nature, and context are vast.
>> 
>> Now, you’re comparing a lambda expression to a let binding? That’s even more nonsensical.
>> 
>> Bye.
>> 
>>> On 27 Dec 2015, at 23:30, Developer <devteam.codafi at gmail.com> wrote:
>>> 
>>> Now, now, that's no way to talk about a century's worth of computing research.
>>> 
>>> Since you have yet to respond to my original point, I'll expound:
>>> 
>>> I see Swift's choice of "in" in context of other programming languages that admit anonymous inner scopes with little fuss.  Those tend to come from the ML-family, which uses
>>> 
>>> // args in scope
>>> let e = expr in body
>>> 
>>> Here, what is lacking is visibility of scope, but what is gained is composability.  Swift takes this a step further with
>>> 
>>> let e = { args in body }(expr)
>>> 
>>> Thus, coming from the C-side of things, you get nearly the same benefits as the former, but with the feel of a C-like language.  To change `in` or permute the ordering of binder, body, or delimiter detracts from Swift's position in either of these.
>>> 
>>> All the best,
>>> 
>>> ~Robert Widmann
>>> 
>>> 2015/12/27 18:07、Alexander Regueiro <alexreg at gmail.com> のメッセージ:
>>> 
>>>> The lambda calculus is a mathematical tool. It’s not designed for readability. Your point is invalid.
>>>> 
>>>>> On 27 Dec 2015, at 23:03, Developer <devteam.codafi at gmail.com> wrote:
>>>>> 
>>>>> With a proper λ, that's the point.  The lambda calculus doesn't focus on the delimiter between the binder and the body because it isn't the important part of an abstraction, the rest is.  I would argue a programming language shouldn't either.  What is to be gained by having more syntax around a construct all about anonymity?
>>>>> 
>>>>> ~Robert Widmann
>>>>> 
>>>>> 2015/12/27 17:56、Alexander Regueiro <alexreg at gmail.com> のメッセージ:
>>>>> 
>>>>>> It’s been agreed by almost everyone that “in” is at the very least a poor delimiter. It’s barely noticeable.
>>>>>> 
>>>>>>> On 27 Dec 2015, at 22:54, Developer <devteam.codafi at gmail.com> wrote:
>>>>>>> 
>>>>>>> Hell, we have Unicode support, why not λ (U+03BB)?  Seriously though, for a C-like language I have to agree that Swift's approach is one of the best.  I can't think of a way of improving it that wouldn't immediately clash with the style and syntax of the language.  Sure you could change a few keywords here and there, but fundamentally 
>>>>>>> 
>>>>>>> { args in body } 
>>>>>>> 
>>>>>>> Strikes a balance between C-like basic blocks and Objective-C-like blocks.  When you start making more of this implicit or shifting it around, you have to necessarily start caring about things like whitespace and implicit scoping (I notice in the example you give, it is immediately less clear which identifiers are bound into what block). Things I don't think Swift wants you to care about, or makes explicit where you should.  Losing a few characters here and there doesn't seem worth it to lose an equal amount of declarative-ness.
>>>>>>> 
>>>>>>> ~Robert Widmann
>>>>>>> 
>>>>>>> 2015/12/27 17:24、Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> のメッセージ:
>>>>>>> 
>>>>>>>>> In this mail I’m answering several statements made in this thread by different people, not only Brent’s mail from which I just picked the following snippet:
>>>>>>>>> 
>>>>>>>>>> let names = people.map => person { person.name }
>>>>>>>>> 
>>>>>>>>> For me that is more difficult to read than
>>>>>>>>> 
>>>>>>>>> let names = people.map { person in person.name }
>>>>>>>>> 
>>>>>>>>> Especially when chaining is used, i.e.
>>>>>>>>> 
>>>>>>>>> let names = people.filter => person { person.isFriend }.map => person { person.name }
>>>>>>>>> 
>>>>>>>>> (or would I have to add parentheses somewhere with this proposed syntax?)
>>>>>>>>> 
>>>>>>>>> vs.
>>>>>>>>> 
>>>>>>>>> let names = people.filter { person in person.isFriend }.map { person in person.name }
>>>>>>>> 
>>>>>>>> I said in the email that => is too visually heavy for this role.
>>>>>>>> 
>>>>>>>> Here's something lighter, although I'm still not satisfied with it, and not seriously suggesting it:
>>>>>>>> 
>>>>>>>> let names = people.map ~ person { person.name }
>>>>>>>> 
>>>>>>>> Or even:
>>>>>>>> 
>>>>>>>> let names = people.map \person { person.name }
>>>>>>>> 
>>>>>>>> However, I'm really struggling to find anything that I actually like here. This may be one of those cases where we dislike what's there and explore a bunch of options, only to find out that the current thing actually is the least bad alternative after all.
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> Brent Royal-Gordon
>>>>>>>> Architechies
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> swift-evolution mailing list
>>>>>>>> swift-evolution at swift.org
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution