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@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.cod...@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 <alex...@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.cod...@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 <alex...@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.cod...@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@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@swift.org
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
