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 <[email protected]> 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 <[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
