So how do you expect me to type "naturally" the character λ? Not all keyboards are equal, are different languages around the world, with different keyboard layouts. However in all I can type "in" but not this symbol that can only reproduce by copying and pasting.
Em dom, 27 de dez de 2015 às 21:58, Developer via swift-evolution < [email protected]> escreveu: > Notation is not an arbitrary construct, and the choice of how to represent > a λ-abstraction isn’t either. When Church designed the calculus, he chose > just 3 simple constructs: variables, abstractions, and applications, to be > the entirety of the language. Readability in the system is derived from > simplicity of notation and concept, not from syntactic noise - far removed > from this system through decades of investigation and simplification by > other logicians and combinatorists. > > I chose my examples from languages that I believe stay truest to the > original vision of a λ - Swift included - because I believe they best > inform my argument that the syntax needn’t change to fit a particular style > because it is, by some definitions, unreadable. In fact, I find it to be > just as readable, if not more, than the other languages I mentioned > precisely because the existing syntax blends in so nicely with the goal of > the past and the syntax we have now. > > I believe that in changing the ‘in’ keyword or the other ideas below > amounts to little more than another permutation of syntax overtop an > already good model. If anything, you really start to lose the original > intent of closures in this language when you start trying to make them look > like JavaScript, Ruby, etc. just to make them “stand out” when in reality > all you’re doing is cluttering a once-simple idea. > > tl;dr Don’t fix what ain’t broke. Don’t complect what ain’t already > simple. > > I hope I’ve explained myself sufficiently well, because I don’t feel like > I got my point across with those last 2 emails. You have my email if you > have anything you want to say to me personally. > > ~Robert Widmann > > > On Dec 27, 2015, at 6:38 PM, Alexander Regueiro <[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
