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