[swift-evolution] Lambda function syntax

[Wallacy]

Sorry, i misread you mail.

Em dom, 27 de dez de 2015 às 23:20, Developer <devteam.codafi at gmail.com>
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 <wallacyf at gmail.com> のメッセージ:
>
>
> 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 <
> swift-evolution at swift.org> 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 <alexreg at gmail.com>
>> 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 <devteam.codafi at gmail.com> 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 <alexreg at gmail.com> のメッセージ:
>> >>
>> >>> 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 <devteam.codafi at gmail.com>
>> 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 <alexreg at gmail.com> のメッセージ:
>> >>>>
>> >>>>> 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 <devteam.codafi at gmail.com>
>> 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 <
>> swift-evolution at swift.org> のメッセージ:
>> >>>>>>
>> >>>>>>>> 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
>> >>>>>>> swift-evolution at swift.org
>> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>>
>> >
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151228/2562296d/attachment.html>