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
