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 <[email protected]> のメッセージ:
> 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 <[email protected]> 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 <[email protected]> のメッセージ:
>>
>>> 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 <[email protected]> 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
>>>> <[email protected]> のメッセージ:
>>>>
>>>>>> 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
>>>>> [email protected]
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
