Sorry, i misread you mail. Em dom, 27 de dez de 2015 às 23:20, Developer <[email protected]> escreveu:
> Oh my, no. I don't intend Swift to become the λ calculus, I was merely > making an analogy (and a joke, 3 replies ago). In the same way that λ is > the simplest set of rules embodying the powerful construct abstraction is, > Swift's syntax for it is probably the simplest and best we can get given > the style of other existing pieces of syntax. Unfortunately, I think > people see math and get a bit freaked out! > > ~Robert Widmann > > 2015/12/27 20:11、Wallacy <[email protected]> のメッセージ: > > > 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
