Re: [swift-evolution] Lambda function syntax

[Thorsten Seitz via swift-evolution]

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 }


Those „=>“ pretty much visually separate the statement in the wrong positions, 
i.e. the parts grouped together visually are

1. people.filter
2. person { person.isFriend }.map
3. person { person.name }

which is simply wrong for the middle part (or parts in case of more chaining).

Whereas having the arguments in the closure separate the parts visually much 
better, keeping the closures together and interspersed with the function names.


With regards to trailing closures: Having them is an important part of DSLs in 
Ruby, Smalltalk and Scala.

See for example the links cited in https://news.ycombinator.com/item?id=7921011 
or the Akka library (http://akka.io) or rake (Ruby’s „make" replacement).

Of course Alexander is right that the concept of a trailing closure works only 
for one closure and not for several. That is indeed a thing where Smalltalk’s 
syntax without any parentheses around function arguments had a really nice 
advantage which is not possible in Swift (although the parameter keywords are 
really great in alleviating this).
But there are so many cases (as the links above demonstrate) where a single 
trailing closure is sufficient that this feature is tremendously useful.


With regards to Haskell: the above example would (typically) look like:

names = map (\person -> name person) . filter (\person -> isFriend person) $ 
people

which also uses only one pair of parentheses just around the lambda expressions 
(because Haskell has neither parentheses around parameters nor around closures).

Visually it actually looks just the same as Swift’s closures (replacing 
parentheses with braces and „->“ with „in“ and dropping the backslash which 
stands in for the greek letter lambda), i.e. visually the parameters of the 
closure are within the parentheses, just like in Swift.
Of course the syntactical meaning of the parentheses is different from that of 
the braces but the visual effect is quite important in my eyes. That helps a 
lot in readability.


With regards to „in“: I personally like it but could also live with something 
like „=>“ or the bar „|“ as used in Ruby (two bars around the params) or 
Smalltalk (just one bar after the params which I would prefer), e.g.

let names = people.map { person | person.name }

although the „in“ definitely looks better with syntax highlighting and when 
using the wrong font like now (where the bar just looks like the upper case 
letter „i“).

I think I said it already: the „in“ reminds me of the let-in-expression of 
Haskell, e.g. „let foo = 3 in …“


-Thorsten___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Wallacy via swift-evolution]

Sorry, i misread you mail.

Em dom, 27 de dez de 2015 às 23:20, Developer 
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  のメッセージ:
>
>
> 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@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 
>> 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  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  のメッセージ:
>> >>
>> >>> 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 
>> 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 

Re: [swift-evolution] Lambda function syntax

[Developer via swift-evolution]

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  のメッセージ:

> 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  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 
>>  のメッセージ:
>> 
 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@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

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  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  のメッセージ:
> 
>> 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  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  のメッセージ:
>>> 
 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  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 
>  のメッセージ:
> 
>>> 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
>> 
>> 

Re: [swift-evolution] Lambda function syntax

[Chris Lattner via swift-evolution]

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 
>  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 
>>  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  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  のメッセージ:
>>> 
 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  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  のメッセージ:
> 
>> 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  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 
>>>  のメッセージ:
>>> 
> 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 

Re: [swift-evolution] Lambda function syntax

[Developer via swift-evolution]

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  のメッセージ:

> 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  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  のメッセージ:
>> 
>>> 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  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 
  のメッセージ:
 
>> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Developer via swift-evolution]

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  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  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  のメッセージ:
>> 
>>> 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  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  のメッセージ:
 
> 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  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 

Re: [swift-evolution] Lambda function syntax

[Developer via swift-evolution]

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  のメッセージ:

> 
> 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 
>>  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  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  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  のメッセージ:
>> >>
>> >>> 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  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 

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

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  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  のメッセージ:
> 
>> 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  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 
>>>  のメッセージ:
>>> 
> 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@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Kevin Ballard via swift-evolution]

By almost everybody that's actually posted to this thread. That's a hugely 
important distinction. Personally, I like "in".

-Kevin Ballard

On Sun, Dec 27, 2015, at 02:56 PM, Alexander Regueiro via swift-evolution wrote:
> 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  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 
> >  のメッセージ:
> > 
> >>> 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@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Thorsten Seitz via swift-evolution]

Just reread my reply and found it a bit unclear, so I'm trying to fix that 
below :-)

> Am 28.12.2015 um 07:08 schrieb Thorsten Seitz via swift-evolution 
> :
> 
> 
> Am 27.12.2015 um 23:24 schrieb Brent Royal-Gordon via swift-evolution 
> :
> 
>>> 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.
> 
> Sorry, I overlooked that.
> 
>> Here's something lighter, although I'm still not satisfied with it, and not 
>> seriously suggesting it:
>> 
>>   let names = people.map ~ person { person.name }
> 
> Symbols have this problem in general because they stand out. But the real 
> problem comes from moving the parameters out of the braces. The symbol only 
> highlights it.

What I wanted to say here is not that there is a problem with symbols standing 
out in general as that is an advantage in general and the very reason to use a 
symbol, but here it is a problem, because the symbol is in the wrong position 
here, so that it breaks the whole expression into the wrong pieces when 
chaining such calls which is a common thing to do, I'd say.

-Thorsten

>> 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.
> 
> :-)
> 
> -Thorsten 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

Yeah, I'm not to bothered by this either way. Back to the discussion about 
closure syntax, maybe?

Sent from my iPhone

> On 24 Dec 2015, at 14:05, Alan Skipp  wrote:
> 
> I'm completely against replacing '->' by ':' it would make unreadable the 
> declaration of a function taking a closure as parameter, or returning one 
> (among other things).
>> 
>> -- 
>> Pierre
> 
> I agree with Pierre. Parameter names and functions as arguments or return 
> values are easily distinguished currently. 
> 
> Replacing -> with :, would severely impact readability. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Tino Heth via swift-evolution]

> I'm completely against replacing '->' by ':' it would make unreadable the 
> declaration of a function taking a closure as parameter, or returning one 
> (among other things).

That's definitely right: Two different separators only shift the problem by one 
level, but hopefully it won't become common to deal with "functions having 
functions as parameters that have function parameters that… ;-)
Also there is the different meaning of ":" ("is a...") and "->" ("returns a…")___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alan Skipp via swift-evolution]

> I'm completely against replacing '->' by ':' it would make unreadable the 
> declaration of a function taking a closure as parameter, or returning one 
> (among other things).
> 
> -- 
> Pierre

I agree with Pierre. Parameter names and functions as arguments or return 
values are easily distinguished currently. 

Replacing -> with :, would severely impact readability. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Craig Cruden via swift-evolution]

Assuming that you are using : for type assignment and -> or => for functions

unlabelled functions would have the syntax  Int => Int not Int: Int.

So func(int : Int, bool: Bool) : Int  // would return a value

func((int: Int, bool: Bool) : Int => Int would return a function with parameter 
of int and and a function f(i) -> int.


> On 2015-12-24, at 19:38:37, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> I'm completely against replacing '->' by ':' it would make unreadable the 
>> declaration of a function taking a closure as parameter, or returning one 
>> (among other things).
> 
> Actually, I find this perfectly readable, though a little bit strange after 
> so long with the current signatures:
> 
>   func indexOf(predicate: Element: Bool): Index? {
>   for (i, elem) in zip(indexes, self) {
>   if predicate(elem) {
>   return i
>   }
>   }
>   return nil
>   }
> 
> Where I *do* foresee big issues is with tuples. Take a look at this 
> declaration:
> 
>   let tuple: (Int: Int, Bool: Bool)
> 
> Does `tuple` contain two unlabeled functions, or two labeled values?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Tino Heth via swift-evolution]

> love trailing closures
I wouldn't go that far and just say "})" looks ugly — but that has the same 
implications ;-)
With parameters, trailing closures loose a lot of their appeal, and an 
alternative syntax ("func(x: Int) {" instead of "{ x: Int in}" isn't that bad 
for trailing closure either.

The only obvious downside is the "$0" shortcut would be confusing with "func() 
{" (but not so much with "func {"…).
Speaking of "$0", you could argue why it is allowed in closures and not in 
methods… but I'm in some discord with $0 anyways:
It is really nice for small constructs, but drawing the line when to discourage 
their use is tough (at least to tough for the compiler to enforce a rule).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[James Campbell via swift-evolution]

I don't think either are that nice, we could do a ruby thing and use "do".
The do expresses that we are passing in a block :)  and the arguments are
on the outside of the closure which matches iit elsewhere:

heyThere() do |hi, there|
{

}

we could allow anon functions like so:

heyThere((hi, there){
})

But then its inconsistent, so I don't mind what swift does now :) as its
consistent whether its a closure block or a argument we are passing in.

Regarding the "=>" vs "in" debate, they are both obtuse to me. In some-ways
"in" is better as it reads to me as "the arguments in this closure" so I
would much prefer "in". I know this is subjective but that's just my two
cents ;)

On Wed, Dec 23, 2015 at 9:42 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> love trailing closures
>
> I wouldn't go that far and just say "})" looks ugly — but that has the
> same implications ;-)
> With parameters, trailing closures loose a lot of their appeal, and an
> alternative syntax ("func(x: Int) {" instead of "{ x: Int in}" isn't that
> bad for trailing closure either.
>
> The only obvious downside is the "$0" shortcut would be confusing with
> "func() {" (but not so much with "func {"…).
> Speaking of "$0", you could argue why it is allowed in closures and not in
> methods… but I'm in some discord with $0 anyways:
> It is really nice for small constructs, but drawing the line when to
> discourage their use is tough (at least to tough for the compiler to
> enforce a rule).
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Brent Royal-Gordon via swift-evolution]

I have to admit I haven't read the entire thread, so maybe I missed discussion 
of this.

I, too, don't like the `params in code` syntax. After a year and a half with 
Swift, I now remember it, but it still reads funny, and I see new developers 
struggle with it frequently. I've also used Ruby quite a bit, but I really 
don't like the `||` syntax there either.

What I would do is pull the parameters/type signature out of the braces and put 
a symbol in front of them. For example:

let names = people.map => person { person.name }

database.saveRecord(record) => record, error {
if let record = record {
completionHandler(true)
}
else {
handleError(error!)
}
}

`=>` is used here merely because it's been discussed upthread; I actually think 
it's a little too heavy for this role, but I don't have a great replacement 
immediately at hand.

A no-parameters closure would not require a `=>`; a bare block would still do 
there. I suppose the capture list would still go before the parameters, but 
after the `=>`. Other closure features remain the same—you can still use the 
`$N` implicit parameters, and you can still use `->` to specify a return value, 
`()` to surround the parameters, `:` to specify exact types, etc.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Pierre Monod-Broca via swift-evolution]

I like that the closure parameters are inside the closure, to me it makes as 
much sense as outside. They're the input, so as much in as out.

I have nothing against `in`, but I wouldn't be against a sensible replacement.
I like `=>`, but I'm concerned it might be confused with `->` by beginners in 
swift.

-- 
Pierre

> Le 23 déc. 2015 à 11:21, Brent Royal-Gordon via swift-evolution 
>  a écrit :
> 
> I have to admit I haven't read the entire thread, so maybe I missed 
> discussion of this.
> 
> I, too, don't like the `params in code` syntax. After a year and a half with 
> Swift, I now remember it, but it still reads funny, and I see new developers 
> struggle with it frequently. I've also used Ruby quite a bit, but I really 
> don't like the `||` syntax there either.
> 
> What I would do is pull the parameters/type signature out of the braces and 
> put a symbol in front of them. For example:
> 
>   let names = people.map => person { person.name }
> 
>   database.saveRecord(record) => record, error {
>   if let record = record {
>   completionHandler(true)
>   }
>   else {
>   handleError(error!)
>   }
>   }
> 
> `=>` is used here merely because it's been discussed upthread; I actually 
> think it's a little too heavy for this role, but I don't have a great 
> replacement immediately at hand.
> 
> A no-parameters closure would not require a `=>`; a bare block would still do 
> there. I suppose the capture list would still go before the parameters, but 
> after the `=>`. Other closure features remain the same—you can still use the 
> `$N` implicit parameters, and you can still use `->` to specify a return 
> value, `()` to surround the parameters, `:` to specify exact types, etc.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Brent Royal-Gordon via swift-evolution]

> I think => may be confusing in many of shown cases. Its a cause/efect symbol 
> and can be also and operator.
> 
> I put again the idea of with for the newcomers:
> 
> with (  parameters ) -> return_type {
> statements
> }
> 
> 
> sorted = names.sort( with(s1, s2){ s1 > s2 } )
> 
> sorted = names.sort( with{ $0 > $1 } )
> 
> 
> sorted = names.sort()  with { $0 > $1 }  
> 
> reversed = names.sort with(s1,s2){
> 
>   //bla bla code
>   return resultVar 
> }
>  
> reversed = names.sort with { $0 > $1 }  

I don't think this is particularly helpful. Even if you don't know what a 
closure is, if you're familiar with any C-like language, or with other parts of 
Swift's syntax, you know that `{ ... }` indicates a piece of code. That's all 
you really need to know in order to understand what `names.sort { $0 > $1 }` 
*means*, even if you don't immediately know how it *works*.

We don't need a keyword hopping up and down shouting "CLOSURE! CLOSURE! 
CLOSURE!"; all we need is a syntactic marker delimiting the boundary between 
the parameter list and whatever's adjacent to it. Your `with` and `delegating` 
keywords hop up and down. The current `in` keyword marks the boundary; so does 
whatever we actually call my proposed `=>` symbol. (Again, I don't actually 
like that specific symbol—think of it as a placeholder.)

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

This is very similar to my proposal. We were later suggesting the use of `=>` 
in place of `in`, but formerly I suggested essentially what you did here, but 
with `func` or `\` in place of `>=` to signify the start of a closure 
expression.

> On 23 Dec 2015, at 10:21, Brent Royal-Gordon  wrote:
> 
> I have to admit I haven't read the entire thread, so maybe I missed 
> discussion of this.
> 
> I, too, don't like the `params in code` syntax. After a year and a half with 
> Swift, I now remember it, but it still reads funny, and I see new developers 
> struggle with it frequently. I've also used Ruby quite a bit, but I really 
> don't like the `||` syntax there either.
> 
> What I would do is pull the parameters/type signature out of the braces and 
> put a symbol in front of them. For example:
> 
>   let names = people.map => person { person.name }
> 
>   database.saveRecord(record) => record, error {
>   if let record = record {
>   completionHandler(true)
>   }
>   else {
>   handleError(error!)
>   }
>   }
> 
> `=>` is used here merely because it's been discussed upthread; I actually 
> think it's a little too heavy for this role, but I don't have a great 
> replacement immediately at hand.
> 
> A no-parameters closure would not require a `=>`; a bare block would still do 
> there. I suppose the capture list would still go before the parameters, but 
> after the `=>`. Other closure features remain the same—you can still use the 
> `$N` implicit parameters, and you can still use `->` to specify a return 
> value, `()` to surround the parameters, `:` to specify exact types, etc.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

Does “in” really make sense semantically though? It seems to have confused 
almost everywhere, and as we’ve discussed, it’s not “delimited enough”.

My recent personal proposal was the syntax:

func x, y, z { … }

– for the reasons/advantages discussed in my post stating the grammar (and 
previous one).

If this can’t be effected, then I would compromise for the syntax that just 
replaces `in` with `>=` in the current syntax.

I also like the proposal of changing `->` to `:` in function type specifiers, 
for consistency. This also frees up another operator.

> On 23 Dec 2015, at 04:02, Jordan Rose  wrote:
> 
> Hi, Alexander. For your most recent version, what does the syntax look like 
> when there are explicit types? As far as I can tell the only change is 
> substituting "in" for "=>", which means taking an existing keyword (from 
> 'for' loops) and replacing it with what's currently a valid operator.
> 
> We definitely thought a lot about closure syntax; what we ended up with
> (a) is concise,
> (b) has some precedent, structurally (Ruby, Smalltalk),
> (c) is easy to parse (does not require unbounded lookahead) and therefore 
> easier to produce diagnostics for, and
> (d) kept the parameter list and return values looking like they do in 
> declarations (when types are included)
> 
> It may not be the prettiest thing in the language, but I'm not sure why any 
> of your proposals are objectively better. The main thing we are missing is 
> that closures do not look like standalone function declarations, but we 
> decided that they're important enough that they need a lightweight syntax. 
> (Compare with JavaScript for a language that did not prioritize this.)
> 
> I personally love trailing closures, both here and in Ruby, so I'd put that 
> down to just as much a matter of opinion as closure syntax.
> 
> Best,
> Jordan
> 
> 
>> On Dec 22, 2015, at 19:48 , Alexander Regueiro via swift-evolution 
>> > wrote:
>> 
>> The standard map syntax is directly inspired by that of C#.
>> 
>> For Swift, I’d be relatively happy with something like the following 
>> (repeating what’s already been said I believe)
>> 
>> map ({ x => x + 5 })
>> 
>> or using trailing closure
>> 
>> map { x => x + 5 }
>> 
>> with the possibility of an additional single-line option:
>> 
>> map ( x => x + 5 )
>> 
>> (which is useful in the case of non-trailing-closure expressions).
>> 
>> Of course, I’d rather remove trailing closures altogether, but I suspect 
>> that won’t happen. :(
>> 
>>> On 23 Dec 2015, at 03:45, Craig Cruden >> > wrote:
>>> 
>>> It has probably been 6 months since I have had time to do anything 
>>> interesting (JDK6 + Oracle SQL recently for contracts recently) so if I am 
>>> messing up terminology or syntax - please excuse me.  I messed a few things 
>>> up and had to open up an old Scala project to remind me what I was doing.
>>> 
>>> 
>>> The standard map syntax for Scala is:
>>> 
>>> a.map(x => x + 5)
>>> 
>>> or using a placeholder (very limited shorthand - cannot use a placeholder 
>>> twice for the same value):
>>> 
>>> a.map(_ + 5)
>>> 
>>> if it is a tuple then
>>> 
>>> a.map(x => f(x._1, x._2))
>>> 
>>> or you can pass in a function block (with pattern matching case)
>>> 
>>> a.map { case (x, y) => (y, x) }
>>> 
>>> there might be some mathematical reason behind the “in” keyword - but it is 
>>> lost on me as well (it has been a good 30 years since University) and gets 
>>> lost on me.  If I had more time I might get use to it.
>>> 
>>> I hope I did not mess up those examples as bad.
>>> 
>>> 
>>>  
>>> 
 On 2015-12-23, at 9:52:46, Andrey Tarantsov > wrote:
 
> foo.map( bar => bar.boz) // single line
 
 Well how important is it to use () instead of {} here?
 
 If you make it
 
 foo.map { bar => bar.boz }
 
 then it's like it is now, but with "in" replace by "=>".
 
> foo.map { (x, y) => x * 5 + y }
 
 I actually like the bare version:
 
 foo.map { x, y => x * 5 + y }
 
 but not in your example (here it looks atrocious). Take this real code, 
 though:
 
 
 constrain(topBlock, tableView, view) { top, tbl, sup in
 top.left  == sup.left + horizPadding
 top.right == sup.right - horizPadding
 top.top   == sup.top  + topPadding
 
 tbl.top== top.bottom + 16
 tbl.bottom == sup.bottom
 
 tbl.left  == sup.left + horizPadding - horizTableHang
 tbl.right == sup.right - horizPadding + horizTableHang
 }
 
 I think the lack of parens is beneficial in reducing the visual noise here.
 
> And yes, I certainly would prefer `=>` rather than `in`.
 
 It seems like the 

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

N.B. My previous observation would also rely on return being optional (at least 
for single-line nested functions / closures). I believe that making return 
statements optional at the end of a function is already being considered under 
another proposal.

> On 21 Dec 2015, at 21:47, Chris Lattner  wrote:
> 
> 
>> On Dec 21, 2015, at 1:33 PM, Alexander Regueiro  wrote:
>> 
>> Hi Chris,
>> 
>> Don’t you think the suggestion is better? I’m happy to formula it in terms 
>> of an E(BNF) grammar if you like. Is this published/available anywhere, for 
>> the current version of Swift?
> 
> My personal opinion is “no”, because it will look very weird in trailing 
> closure, in the argument lists for function calls, etc.
> 
> Further, it would not permit dropping ()’s on closure arguments, you wouldn’t 
> be able to write this:
> 
> foo({ lhs, rhs in … })
> 
> because the  comma would be exposed out to the function call.
> 
> The grammar is described in the reference section of TSPL:
> https://swift.org/documentation/
> 
> In addition to proposing EBNF, please consider the existing grammar so that 
> the new proposal isn’t completely ambiguous.  What you are proposing would be 
> an extremely tricky thing to do.
> 
> -Chris
> 
> 
>> 
>> Thanks.
>> 
>>> On 21 Dec 2015, at 19:22, Chris Lattner  wrote:
>>> 
 
 On Dec 21, 2015, at 11:20 AM, Alexander Regueiro via swift-evolution 
  wrote:
 
 Does anyone not like the current syntax for this?
 
 I would propose changing it from:
 
 { (param_list) -> return_type in … }
 
 to something cleaner like:
 
 (param_list) -> return_type => { … }
 
 where I’m not so bothered about the `=>` separator (could be `:`, `,`, or 
 indeed `in`).
 
 The braces being around the type specifier as well as function body rather 
 bothers me. Surely it would be more consistent just to have the braces 
 around the function body, and then the type specifier preceding this?
>>> 
>>> Hi Alexander,
>>> 
>>> We’re open in principle to replacing closure syntax with something better, 
>>> but A) it needs to be actually better, and B) it needs to fit with the 
>>> swift grammar.  If you’re interested in pushing forward in this area, 
>>> please familiarize yourself with the structure of the grammar and propose 
>>> what you’re thinking in terms of a diff to it.  Thanks,
>>> 
>>> -Chris
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

I’m against everything here. It’s universally worse, in my view.

> On 23 Dec 2015, at 10:05, James Campbell  wrote:
> 
> I don't think either are that nice, we could do a ruby thing and use "do". 
> The do expresses that we are passing in a block :)  and the arguments are on 
> the outside of the closure which matches iit elsewhere:
> 
> heyThere() do |hi, there|
> {
> 
> }
> 
> we could allow anon functions like so:
> 
> heyThere((hi, there){
> })
> 
> But then its inconsistent, so I don't mind what swift does now :) as its 
> consistent whether its a closure block or a argument we are passing in.
> 
> Regarding the "=>" vs "in" debate, they are both obtuse to me. In some-ways 
> "in" is better as it reads to me as "the arguments in this closure" so I 
> would much prefer "in". I know this is subjective but that's just my two 
> cents ;)
> 
> On Wed, Dec 23, 2015 at 9:42 AM, Tino Heth via swift-evolution 
> > wrote:
> 
>> love trailing closures
> I wouldn't go that far and just say "})" looks ugly — but that has the same 
> implications ;-)
> With parameters, trailing closures loose a lot of their appeal, and an 
> alternative syntax ("func(x: Int) {" instead of "{ x: Int in}" isn't that bad 
> for trailing closure either.
> 
> The only obvious downside is the "$0" shortcut would be confusing with 
> "func() {" (but not so much with "func {"…).
> Speaking of "$0", you could argue why it is allowed in closures and not in 
> methods… but I'm in some discord with $0 anyways:
> It is really nice for small constructs, but drawing the line when to 
> discourage their use is tough (at least to tough for the compiler to enforce 
> a rule).
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> 
> -- 
>  Wizard
> ja...@supmenow.com 
> +44 7523 279 698

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

I agree on this. For large closures, `$0` isn’t very clear what you’re 
referring to. Personally, I’d rather remove them altogether, but I don’t want 
to start a subdiscussion on that here.

> On 23 Dec 2015, at 09:42, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> love trailing closures
> I wouldn't go that far and just say "})" looks ugly — but that has the same 
> implications ;-)
> With parameters, trailing closures loose a lot of their appeal, and an 
> alternative syntax ("func(x: Int) {" instead of "{ x: Int in}" isn't that bad 
> for trailing closure either.
> 
> The only obvious downside is the "$0" shortcut would be confusing with 
> "func() {" (but not so much with "func {"…).
> Speaking of "$0", you could argue why it is allowed in closures and not in 
> methods… but I'm in some discord with $0 anyways:
> It is really nice for small constructs, but drawing the line when to 
> discourage their use is tough (at least to tough for the compiler to enforce 
> a rule).

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

I just thought, another way of looking at this proposal is by merging the 
nested function and closure expression features. Or rather, simply removing 
current closure syntax and allowing nested functions to be specified inline 
(and adding capture support to nested functions). This would not only simplify 
the language, but improve style, in quite an elegant way.

> On 21 Dec 2015, at 22:26, Alexander Regueiro  wrote:
> 
> Thanks for clarifying.
> 
> In that case, I would propose grammar for capture expressions, which should 
> drop in without modifications elsewhere (I say tentatively):
> 
> closure-expression → “func" closure-signature_opt { statements }
> ‌ closure-signature → parameter-clause function-result_opt
> ‌ closure-signature → identifier-list function-result_opt
> ‌ closure-signature → capture-list parameter-clause function-result_opt
> ‌ closure-signature → capture-list identifier-list function-result_opt
> ‌ closure-signature → capture-list
> ‌ capture-list → [ capture-list-items ]
> ‌ capture-list-items → capture-list-item | capture-list-item , 
> capture-list-items
> ‌ capture-list-item → capture-specifier_opt expression
> ‌ capture-specifier → weak | unowned | unowned(safe) | unowned(unsafe)
> 
> I am open to whether the introducing keyword is “func” (overloading the 
> existing keyword but in an evidently separate context, and unambiguously I 
> believe) – or “lambda” (like Python), or “\” (like Haskell) – or even 
> something like “cl” (for Closure). Note that the aforementioned adds an 
> additional keyword, but also removes the the “in” keyword. For reasons 
> mentioned in my previous message, I believe this syntax is both clearer and 
> more consistent. It’s also more in line with other widespread languages (in 
> my experience).
> 
> For reference, the current grammar is:
> 
> closure-expression → { closure-signature_opt statements }
> ‌ closure-signature → parameter-clause function-result_opt “in"
> ‌ closure-signature → identifier-list function-result_opt “in"
> ‌ closure-signature → capture-list parameter-clause function-result_opt “in"
> ‌ closure-signature → capture-list identifier-list function-result_opt "in"
> ‌ closure-signature → capture-list “in"
> ‌ capture-list → [ capture-list-items ]
> ‌ capture-list-items → capture-list-item | capture-list-item , 
> capture-list-items
> ‌ capture-list-item → capture-specifier_opt expression
> ‌ capture-specifier → weak | unowned | unowned(safe) | unowned(unsafe)
> 
> Also, I didn’t bother making braces optional, since I hear that the original 
> language designers wanted to avoid the problems that optional braces have the 
> potential to introduce (e.g. in C-style languages). There are no round 
> brackets used in my above syntax either, which is consistent with their 
> absence in expressions in conditional and loop statements.
> 
> Thoughts?
> 
>> On 21 Dec 2015, at 21:47, Chris Lattner  wrote:
>> 
>> 
>>> On Dec 21, 2015, at 1:33 PM, Alexander Regueiro  wrote:
>>> 
>>> Hi Chris,
>>> 
>>> Don’t you think the suggestion is better? I’m happy to formula it in terms 
>>> of an E(BNF) grammar if you like. Is this published/available anywhere, for 
>>> the current version of Swift?
>> 
>> My personal opinion is “no”, because it will look very weird in trailing 
>> closure, in the argument lists for function calls, etc.
>> 
>> Further, it would not permit dropping ()’s on closure arguments, you 
>> wouldn’t be able to write this:
>> 
>> foo({ lhs, rhs in … })
>> 
>> because the  comma would be exposed out to the function call.
>> 
>> The grammar is described in the reference section of TSPL:
>> https://swift.org/documentation/
>> 
>> In addition to proposing EBNF, please consider the existing grammar so that 
>> the new proposal isn’t completely ambiguous.  What you are proposing would 
>> be an extremely tricky thing to do.
>> 
>> -Chris
>> 
>> 
>>> 
>>> Thanks.
>>> 
 On 21 Dec 2015, at 19:22, Chris Lattner  wrote:
 
> 
> On Dec 21, 2015, at 11:20 AM, Alexander Regueiro via swift-evolution 
>  wrote:
> 
> Does anyone not like the current syntax for this?
> 
> I would propose changing it from:
> 
> { (param_list) -> return_type in … }
> 
> to something cleaner like:
> 
> (param_list) -> return_type => { … }
> 
> where I’m not so bothered about the `=>` separator (could be `:`, `,`, or 
> indeed `in`).
> 
> The braces being around the type specifier as well as function body 
> rather bothers me. Surely it would be more consistent just to have the 
> braces around the function body, and then the type specifier preceding 
> this?
 
 Hi Alexander,
 
 We’re open in principle to replacing closure syntax with something better, 
 but A) it needs to be actually better, and B) it needs to fit with the 
 swift grammar.  If you’re 

Re: [swift-evolution] Lambda function syntax

[Brent Royal-Gordon via swift-evolution]

> This is very similar to my proposal. We were later suggesting the use of `=>` 
> in place of `in`, but formerly I suggested essentially what you did here, but 
> with `func` or `\` in place of `>=` to signify the start of a closure 
> expression.

It seems, though, that you thought *all* closures should be marked with this 
character, even parameterless ones. Whereas I propose that:

>> A no-parameters closure would not require a `=>`; a bare block would still 
>> do there.

Perhaps it's a difference in perspective—I've spent nearly my entire career 
using languages where closures were common—but I really don't think closures 
need a big, obvious syntactic marker. All we need is a good way to mark the 
ambiguous end of the parameter list (the front end if it's outside the closure, 
the back end if it's inside).

Closures are not conceptually a terribly difficult feature—they're just omitted 
from many languages because they're difficult to *implement*. We have to be 
careful not to make their syntax heavier than it needs to be.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

Marking the *start* of a closure is more difficult than marking the end of the 
parameter the list. The end of the parameter list and start of the body of a 
closure (lambda expression) can be easily delineated by `{` in my scheme.

> On 23 Dec 2015, at 21:15, Brent Royal-Gordon  wrote:
> 
>> This is very similar to my proposal. We were later suggesting the use of 
>> `=>` in place of `in`, but formerly I suggested essentially what you did 
>> here, but with `func` or `\` in place of `>=` to signify the start of a 
>> closure expression.
> 
> It seems, though, that you thought *all* closures should be marked with this 
> character, even parameterless ones. Whereas I propose that:
> 
>>> A no-parameters closure would not require a `=>`; a bare block would still 
>>> do there.
> 
> Perhaps it's a difference in perspective—I've spent nearly my entire career 
> using languages where closures were common—but I really don't think closures 
> need a big, obvious syntactic marker. All we need is a good way to mark the 
> ambiguous end of the parameter list (the front end if it's outside the 
> closure, the back end if it's inside).
> 
> Closures are not conceptually a terribly difficult feature—they're just 
> omitted from many languages because they're difficult to *implement*. We have 
> to be careful not to make their syntax heavier than it needs to be.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Daniel Valls Estella via swift-evolution]

I think => may be confusing in many of shown cases. Its a cause/efect symbol 
and can be also and operator.

I put again the idea of with for the newcomers:

with (  parameters ) -> return_type {
statements
}


sorted = names.sort( with(s1, s2){ s1 > s2 } )

sorted = names.sort( with{ $0 > $1 } )


sorted = names.sort()  with { $0 > $1 }  

reversed = names.sort with(s1,s2){

//bla bla code
return resultVar 
}
 
reversed = names.sort with { $0 > $1 }  


But thinking about it, what we are really always doing with clousures is 
solving a quicky tiny delegation pattern. Maybe we could name it what it is. 
Too long word, but just to brainstorm.

delegating (  parameters ) -> return_type {
statements
}


sorted = names.sort( delegating(s1, s2){ s1 > s2 } )

sorted = names.sort( delegating{ $0 > $1 } )


sorted = names.sort()  delegating{ $0 > $1 }  

reversed = names.sort delegating(s1,s2){

//bla bla code
return resultVar 
}
 
reversed = names.sort delegating{ $0 > $1 }



:)

> El 23 des 2015, a les 12:49, Pierre Monod-Broca via swift-evolution 
>  va escriure:
> 
> I like that the closure parameters are inside the closure, to me it makes as 
> much sense as outside. They're the input, so as much in as out.
> 
> I have nothing against `in`, but I wouldn't be against a sensible replacement.
> I like `=>`, but I'm concerned it might be confused with `->` by beginners in 
> swift.
> 
> -- 
> Pierre
> 
>> Le 23 déc. 2015 à 11:21, Brent Royal-Gordon via swift-evolution 
>> > a écrit :
>> 
>> I have to admit I haven't read the entire thread, so maybe I missed 
>> discussion of this.
>> 
>> I, too, don't like the `params in code` syntax. After a year and a half with 
>> Swift, I now remember it, but it still reads funny, and I see new developers 
>> struggle with it frequently. I've also used Ruby quite a bit, but I really 
>> don't like the `||` syntax there either.
>> 
>> What I would do is pull the parameters/type signature out of the braces and 
>> put a symbol in front of them. For example:
>> 
>>  let names = people.map => person { person.name }
>> 
>>  database.saveRecord(record) => record, error {
>>  if let record = record {
>>  completionHandler(true)
>>  }
>>  else {
>>  handleError(error!)
>>  }
>>  }
>> 
>> `=>` is used here merely because it's been discussed upthread; I actually 
>> think it's a little too heavy for this role, but I don't have a great 
>> replacement immediately at hand.
>> 
>> A no-parameters closure would not require a `=>`; a bare block would still 
>> do there. I suppose the capture list would still go before the parameters, 
>> but after the `=>`. Other closure features remain the same—you can still use 
>> the `$N` implicit parameters, and you can still use `->` to specify a return 
>> value, `()` to surround the parameters, `:` to specify exact types, etc.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[James Campbell via swift-evolution]

Why not just do ?

On Wed, Dec 23, 2015 at 1:02 PM, Daniel Valls Estella via swift-evolution <
swift-evolution@swift.org> wrote:

> I think => may be confusing in many of shown cases. Its a cause/efect
> symbol and can be also and operator.
>
> I put again the idea of with for the newcomers:
>
> with (  *parameters* ) -> *return_type* {
> *statements*
> }
>
>
> sorted = names.sort( *with*(s1, s2){ s1 > s2 } )
>
> sorted = names.sort( *with*{ $0 > $1 } )
>
>
> sorted = names.sort()  *with* { $0 > $1 }
>
> reversed = names.sort *with*(s1,s2){
>
> //bla bla code
> return resultVar
> }
>
> reversed = names.sort *with* { $0 > $1 }
>
>
> But thinking about it, what we are really always doing with clousures is
> solving a quicky tiny delegation pattern. Maybe we could name it what it
> is. Too long word, but just to brainstorm.
>
> delegating (  *parameters* ) -> *return_type* {
> *statements*
> }
>
>
> sorted = names.sort( *delegating*(s1, s2){ s1 > s2 } )
>
> sorted = names.sort( *delegating*{ $0 > $1 } )
>
>
> sorted = names.sort()  *delegating*{ $0 > $1 }
>
> reversed = names.sort *delegating*(s1,s2){
>
> //bla bla code
> return resultVar
> }
>
> reversed = names.sort *delegating*{ $0 > $1 }
>
>
>
> :)
>
> El 23 des 2015, a les 12:49, Pierre Monod-Broca via swift-evolution <
> swift-evolution@swift.org> va escriure:
>
> I like that the closure parameters are inside the closure, to me it makes
> as much sense as outside. They're the input, so as much in as out.
>
> I have nothing against `in`, but I wouldn't be against a sensible
> replacement.
> I like `=>`, but I'm concerned it might be confused with `->` by beginners
> in swift.
>
> --
> Pierre
>
> Le 23 déc. 2015 à 11:21, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I have to admit I haven't read the entire thread, so maybe I missed
> discussion of this.
>
> I, too, don't like the `params in code` syntax. After a year and a half
> with Swift, I now remember it, but it still reads funny, and I see new
> developers struggle with it frequently. I've also used Ruby quite a bit,
> but I really don't like the `||` syntax there either.
>
> What I would do is pull the parameters/type signature out of the braces
> and put a symbol in front of them. For example:
>
> let names = people.map => person { person.name }
>
> database.saveRecord(record) => record, error {
> if let record = record {
> completionHandler(true)
> }
> else {
> handleError(error!)
> }
> }
>
> `=>` is used here merely because it's been discussed upthread; I actually
> think it's a little too heavy for this role, but I don't have a great
> replacement immediately at hand.
>
> A no-parameters closure would not require a `=>`; a bare block would still
> do there. I suppose the capture list would still go before the parameters,
> but after the `=>`. Other closure features remain the same—you can still
> use the `$N` implicit parameters, and you can still use `->` to specify a
> return value, `()` to surround the parameters, `:` to specify exact types,
> etc.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

This was my first proposal, and was changed my second, but this syntax is 
inspired by C#, where a lambda expression is of one of the following forms:

(Type1 param1, …) => foo // single-statement expression
(Type1 param1, …) => { …; return foo; } // multi-statement expression

Haskell also uses syntax closer to this than to Swift, not to mention ML/F#.

> On 23 Dec 2015, at 02:30, Andrey Tarantsov  wrote:
> 
> So I believe the opinion of the core team and the community would be 
> generally in opposition to the style you want. I understand your arguments, 
> but somehow they are against the entire experience of me (and, presumably, 
> others) as developers.
> 
> To continue our friendly banter, though, do you mind sharing your background? 
> When I read this, I wasn't sure if you're serious or trolling:
> 
>> I would propose changing it from:
>> 
>> { (param_list) -> return_type in … }
>> 
>> to something cleaner like:
>> 
>> (param_list) -> return_type => { … }
> 
> I wonder if doing something like Haskel a lot makes you more used to that 
> sort of arrow constructs?
> 
> This is written in good faith; I hope I used the right tone to indicate that.
> 
> A.
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Andrey Tarantsov via swift-evolution]

One thing I'm really bothered by in C# and ES6 are no-argument methods:

() => { foo() }   // GROSS

The syntax of C# isn't so bad, though, when there's no return type:

foo.map((bar) => bar.boz)

but those double-parens bother me and my eyes a bit, so this definitely looks 
better:

foo.map { (bar) => bar.boz }

I think I'd even prefer that to:

foo.map { (bar) in bar.boz }


What if we just agreed to replace "in" with "=>"? Would that be an improvement 
in your eyes? I could stand behind that proposal.

(btw Chris & team — THANK YOU for the Ruby-style trailing closure syntax, it 
was such a treat to see it last summer!)

A.


> On Dec 23, 2015, at 8:33 AM, Alexander Regueiro  wrote:
> 
> This was my first proposal, and was changed my second, but this syntax is 
> inspired by C#, where a lambda expression is of one of the following forms:
> 
> (Type1 param1, …) => foo // single-statement expression
> (Type1 param1, …) => { …; return foo; } // multi-statement expression
> 
> Haskell also uses syntax closer to this than to Swift, not to mention ML/F#.
> 
>> On 23 Dec 2015, at 02:30, Andrey Tarantsov  wrote:
>> 
>> So I believe the opinion of the core team and the community would be 
>> generally in opposition to the style you want. I understand your arguments, 
>> but somehow they are against the entire experience of me (and, presumably, 
>> others) as developers.
>> 
>> To continue our friendly banter, though, do you mind sharing your 
>> background? When I read this, I wasn't sure if you're serious or trolling:
>> 
>>> I would propose changing it from:
>>> 
>>> { (param_list) -> return_type in … }
>>> 
>>> to something cleaner like:
>>> 
>>> (param_list) -> return_type => { … }
>> 
>> I wonder if doing something like Haskel a lot makes you more used to that 
>> sort of arrow constructs?
>> 
>> This is written in good faith; I hope I used the right tone to indicate that.
>> 
>> A.
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Craig Cruden via swift-evolution]

I am joining this discussion a little late - so I would not be surprised if 
discussed earlier.

but:  

My preference would be:

foo.map( bar => bar.boz) // single line

or 

foo.map { bar =>
 ….
  } 

if more than one line

if there are multiple values then:

foo.map { (x, y) => x * 5 + y }




> On 2015-12-23, at 9:39:03, Andrey Tarantsov via swift-evolution 
>  wrote:
> 
> One thing I'm really bothered by in C# and ES6 are no-argument methods:
> 
> () => { foo() }   // GROSS
> 
> The syntax of C# isn't so bad, though, when there's no return type:
> 
> foo.map((bar) => bar.boz)
> 
> but those double-parens bother me and my eyes a bit, so this definitely looks 
> better:
> 
> foo.map { (bar) => bar.boz }
> 
> I think I'd even prefer that to:
> 
> foo.map { (bar) in bar.boz }
> 
> 
> What if we just agreed to replace "in" with "=>"? Would that be an 
> improvement in your eyes? I could stand behind that proposal.
> 
> (btw Chris & team — THANK YOU for the Ruby-style trailing closure syntax, it 
> was such a treat to see it last summer!)
> 
> A.
> 
> 
>> On Dec 23, 2015, at 8:33 AM, Alexander Regueiro  wrote:
>> 
>> This was my first proposal, and was changed my second, but this syntax is 
>> inspired by C#, where a lambda expression is of one of the following forms:
>> 
>> (Type1 param1, …) => foo // single-statement expression
>> (Type1 param1, …) => { …; return foo; } // multi-statement expression
>> 
>> Haskell also uses syntax closer to this than to Swift, not to mention ML/F#.
>> 
>>> On 23 Dec 2015, at 02:30, Andrey Tarantsov  wrote:
>>> 
>>> So I believe the opinion of the core team and the community would be 
>>> generally in opposition to the style you want. I understand your arguments, 
>>> but somehow they are against the entire experience of me (and, presumably, 
>>> others) as developers.
>>> 
>>> To continue our friendly banter, though, do you mind sharing your 
>>> background? When I read this, I wasn't sure if you're serious or trolling:
>>> 
 I would propose changing it from:
 
 { (param_list) -> return_type in … }
 
 to something cleaner like:
 
 (param_list) -> return_type => { … }
>>> 
>>> I wonder if doing something like Haskel a lot makes you more used to that 
>>> sort of arrow constructs?
>>> 
>>> This is written in good faith; I hope I used the right tone to indicate 
>>> that.
>>> 
>>> A.
>>> 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

Why not curly braces for single-line and multi-line cases? About the brackets 
around multiple parameters: like I said before, no strong opinion either way.

> On 23 Dec 2015, at 02:46, Craig Cruden  wrote:
> 
> I am joining this discussion a little late - so I would not be surprised if 
> discussed earlier.
> 
> but:  
> 
> My preference would be:
> 
> foo.map( bar => bar.boz) // single line
> 
> or 
> 
> foo.map { bar =>
> ….
>  } 
> 
> if more than one line
> 
> if there are multiple values then:
> 
> foo.map { (x, y) => x * 5 + y }
> 
> 
> 
> 
>> On 2015-12-23, at 9:39:03, Andrey Tarantsov via swift-evolution 
>>  wrote:
>> 
>> One thing I'm really bothered by in C# and ES6 are no-argument methods:
>> 
>> () => { foo() }   // GROSS
>> 
>> The syntax of C# isn't so bad, though, when there's no return type:
>> 
>> foo.map((bar) => bar.boz)
>> 
>> but those double-parens bother me and my eyes a bit, so this definitely 
>> looks better:
>> 
>> foo.map { (bar) => bar.boz }
>> 
>> I think I'd even prefer that to:
>> 
>> foo.map { (bar) in bar.boz }
>> 
>> 
>> What if we just agreed to replace "in" with "=>"? Would that be an 
>> improvement in your eyes? I could stand behind that proposal.
>> 
>> (btw Chris & team — THANK YOU for the Ruby-style trailing closure syntax, it 
>> was such a treat to see it last summer!)
>> 
>> A.
>> 
>> 
>>> On Dec 23, 2015, at 8:33 AM, Alexander Regueiro  wrote:
>>> 
>>> This was my first proposal, and was changed my second, but this syntax is 
>>> inspired by C#, where a lambda expression is of one of the following forms:
>>> 
>>> (Type1 param1, …) => foo // single-statement expression
>>> (Type1 param1, …) => { …; return foo; } // multi-statement expression
>>> 
>>> Haskell also uses syntax closer to this than to Swift, not to mention ML/F#.
>>> 
 On 23 Dec 2015, at 02:30, Andrey Tarantsov  wrote:
 
 So I believe the opinion of the core team and the community would be 
 generally in opposition to the style you want. I understand your 
 arguments, but somehow they are against the entire experience of me (and, 
 presumably, others) as developers.
 
 To continue our friendly banter, though, do you mind sharing your 
 background? When I read this, I wasn't sure if you're serious or trolling:
 
> I would propose changing it from:
> 
> { (param_list) -> return_type in … }
> 
> to something cleaner like:
> 
> (param_list) -> return_type => { … }
 
 I wonder if doing something like Haskel a lot makes you more used to that 
 sort of arrow constructs?
 
 This is written in good faith; I hope I used the right tone to indicate 
 that.
 
 A.
 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

>> I’ve also explained the big problem with trailing closures already. And 
>> closures are really *not* control flow statements, so treating like them is 
>> just a fallacy and source of confusion.
> 
> Trailing closures allow you to write constructs that look and act as if they 
> were control flow statements, which in practice is quite useful.

It really just means you put the close bracket for a function call (parameter 
list) before the actual parameters end. Which not only doesn’t save any real 
space (2 characters if you’re lucky, but quite often 0), but it belies the 
semantics of passing arguments to function, at such trifling benefit.

> Closures do have control flow ramifications when reading code: the meaning of 
> `return` inside a closure is different from its meaning in nearby code.

Sure, but that doesn’t mean closures are control-flow elements or statements. 
Also, I think my above point makes this rather irrelevant anyway.

> I personally favored `func` as the introducer for closures for precisely that 
> reason. The presence of `func` would make it easier to recognize that there 
> is something additional going on here, such as variable captures and `return` 
> hijacking. Be warned that I lost that argument internally long ago.

Did you have anyone else on that side? :) I think if another public support can 
be drummed up, it should be on the cards again.

> 
>> There are other arguments against it too, like it doesn’t generalise well 
>> (at all) to multiple closure arguments.
> 
> The argument that a feature does not generalize becomes much weaker when the 
> special case is important enough. Single-closure argument lists like map and 
> dispatch… and with… are common enough that special treatment is warranted.

Sure, but then what's the benefit for single-closure argument lists in the 
first place? I still don’t say any. Honestly, it just looks like a confusing 
way to put the brackets in another place, at the cost of confusing people and 
making your function call look like a function definition. (Great!)


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Greg Parker via swift-evolution]

> On Dec 22, 2015, at 3:45 PM, Alexander Regueiro via swift-evolution 
>  wrote:
> 
> I’ve also explained the big problem with trailing closures already. And 
> closures are really *not* control flow statements, so treating like them is 
> just a fallacy and source of confusion.

Trailing closures allow you to write constructs that look and act as if they 
were control flow statements, which in practice is quite useful.

Closures do have control flow ramifications when reading code: the meaning of 
`return` inside a closure is different from its meaning in nearby code.

I personally favored `func` as the introducer for closures for precisely that 
reason. The presence of `func` would make it easier to recognize that there is 
something additional going on here, such as variable captures and `return` 
hijacking. Be warned that I lost that argument internally long ago.


> There are other arguments against it too, like it doesn’t generalise well (at 
> all) to multiple closure arguments.

The argument that a feature does not generalize becomes much weaker when the 
special case is important enough. Single-closure argument lists like map and 
dispatch… and with… are common enough that special treatment is warranted.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Craig Cruden via swift-evolution]

It would not prevent curly brackets for single-line cases…. just the difference 
between a map function call map() vs infix with scope.





> On 2015-12-23, at 9:48:24, Alexander Regueiro  wrote:
> 
> Why not curly braces for single-line and multi-line cases? About the brackets 
> around multiple parameters: like I said before, no strong opinion either way.
> 
>> On 23 Dec 2015, at 02:46, Craig Cruden  wrote:
>> 
>> I am joining this discussion a little late - so I would not be surprised if 
>> discussed earlier.
>> 
>> but:  
>> 
>> My preference would be:
>> 
>> foo.map( bar => bar.boz) // single line
>> 
>> or 
>> 
>> foo.map { bar =>
>>….
>> } 
>> 
>> if more than one line
>> 
>> if there are multiple values then:
>> 
>> foo.map { (x, y) => x * 5 + y }
>> 
>> 
>> 
>> 
>>> On 2015-12-23, at 9:39:03, Andrey Tarantsov via swift-evolution 
>>>  wrote:
>>> 
>>> One thing I'm really bothered by in C# and ES6 are no-argument methods:
>>> 
>>> () => { foo() }   // GROSS
>>> 
>>> The syntax of C# isn't so bad, though, when there's no return type:
>>> 
>>> foo.map((bar) => bar.boz)
>>> 
>>> but those double-parens bother me and my eyes a bit, so this definitely 
>>> looks better:
>>> 
>>> foo.map { (bar) => bar.boz }
>>> 
>>> I think I'd even prefer that to:
>>> 
>>> foo.map { (bar) in bar.boz }
>>> 
>>> 
>>> What if we just agreed to replace "in" with "=>"? Would that be an 
>>> improvement in your eyes? I could stand behind that proposal.
>>> 
>>> (btw Chris & team — THANK YOU for the Ruby-style trailing closure syntax, 
>>> it was such a treat to see it last summer!)
>>> 
>>> A.
>>> 
>>> 
 On Dec 23, 2015, at 8:33 AM, Alexander Regueiro  wrote:
 
 This was my first proposal, and was changed my second, but this syntax is 
 inspired by C#, where a lambda expression is of one of the following forms:
 
 (Type1 param1, …) => foo // single-statement expression
 (Type1 param1, …) => { …; return foo; } // multi-statement expression
 
 Haskell also uses syntax closer to this than to Swift, not to mention 
 ML/F#.
 
> On 23 Dec 2015, at 02:30, Andrey Tarantsov  wrote:
> 
> So I believe the opinion of the core team and the community would be 
> generally in opposition to the style you want. I understand your 
> arguments, but somehow they are against the entire experience of me (and, 
> presumably, others) as developers.
> 
> To continue our friendly banter, though, do you mind sharing your 
> background? When I read this, I wasn't sure if you're serious or trolling:
> 
>> I would propose changing it from:
>> 
>> { (param_list) -> return_type in … }
>> 
>> to something cleaner like:
>> 
>> (param_list) -> return_type => { … }
> 
> I wonder if doing something like Haskel a lot makes you more used to that 
> sort of arrow constructs?
> 
> This is written in good faith; I hope I used the right tone to indicate 
> that.
> 
> A.
> 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

Sorry, but I don’t think you could be more wrong on every point. I’ve clearly 
detailed why my solution is superior (both factually and in my opinion), and I 
can only see subjective “dislike this”.

Using “func” or “lambda” outside is uglier than “in” inside the braes? Really? 
That just boggles my mind. Sure, maybe Ruby does, but the vast majority of 
languages shun this approach. C# for example has a lovely, crystal clear syntax 
for lambda expressions. So does Haskell, like I’ve mentioned.

I’ve also explained the big problem with trailing closures already. And 
closures are really *not* control flow statements, so treating like them is 
just a fallacy and source of confusion. There are other arguments against it 
too, like it doesn’t generalise well (at all) to multiple closure arguments.

Ultimately, the key points when judging how worthwhile a feature are 1) how big 
a feature is it? 2) how much does it add?. I’d say that for trailing closures, 
the answer to 1) is “moderate”, and 2) is “next to nothing”.

> On 22 Dec 2015, at 06:57, Thorsten Seitz  wrote:
> 
> Well, I'm actually happy with the current closure syntax as it allows very 
> succinct simple cases and trailing closures as Chris has already pointed out.
> 
>> Am 21.12.2015 um 23:44 schrieb Alexander Regueiro via swift-evolution 
>> :
>> 
>> Okay, I assume you are aware this essentially the same syntax as used in 
>> languages like C# and Python, yes? I’m not sure there are any problems in 
>> those languages with it.
>> 
>>> If you dig through (very early) history you’ll see that we had this. There 
>>> are a couple of problems with it:
>>> 
>>> 1) It punishes simple cases like “X.sort { $1 < $0 }”, along with lots of 
>>> simple map and filter closures.
>> 
>> Not really. The above example would just be `X.sort func { $1 < $0 }” or 
>> "X.sort \ { $1 < $0 }` in my proposed syntax. Also, it would be nice to have 
>> all operators implicitly
> 
> Having "func" or the backslash crammed in there is really ugly and unreadable 
> IMHO.
> 
> And in Haskell you don't have braces for the body to begin with and you would 
> have to enclose the closure in parenthesis if it is part of an expression 
> like your examples so in effect it would look quite similar, i.e. having the 
> parameters within the parenthesis (sure, the semantics are different, but I 
> made argument just to demonstrate that what looks good in one syntactic 
> environment might not look good in another).
> 
>>> 2) It reads really weird in trailing closure cases.
>> 
>> Honestly, I strongly dislike trailing closures. I don’t think they add much, 
>> and moreover they use a confusing syntax that make the whole function call 
>> look superficially like a function declaration (or indeed the whole thing 
>> being a closure).
> 
> Trailing closures are a great feature IMHO because they make the code much 
> more readable by allowing constructs to look similar to control flow 
> statements.
> This allows creating very readable DSLs.
> 
> 
>>> Lets step back: What problems are you trying to solve with the current 
>>> closure syntax?
>> 
>> Readability, mainly. I think this is a big improvement. 
> 
> Well, I think it's the opposite for the simple cases and for trailing 
> closures. 
> 
> 
>> Then there’s similarity with other languages, which is minor, but nice. I 
>> don’t know any language that uses a syntax like the current one of Swift.
> 
> Smalltalk and Ruby immediately come to mind and I'm sure there are others.
> 
> Scala has a trailing closure syntax which is similar to Swift's syntax as 
> well.
> 
> -Thorsten 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

The standard map syntax is directly inspired by that of C#.

For Swift, I’d be relatively happy with something like the following (repeating 
what’s already been said I believe)

map ({ x => x + 5 })

or using trailing closure

map { x => x + 5 }

with the possibility of an additional single-line option:

map ( x => x + 5 )

(which is useful in the case of non-trailing-closure expressions).

Of course, I’d rather remove trailing closures altogether, but I suspect that 
won’t happen. :(

> On 23 Dec 2015, at 03:45, Craig Cruden  wrote:
> 
> It has probably been 6 months since I have had time to do anything 
> interesting (JDK6 + Oracle SQL recently for contracts recently) so if I am 
> messing up terminology or syntax - please excuse me.  I messed a few things 
> up and had to open up an old Scala project to remind me what I was doing.
> 
> 
> The standard map syntax for Scala is:
> 
>   a.map(x => x + 5)
> 
> or using a placeholder (very limited shorthand - cannot use a placeholder 
> twice for the same value):
> 
>   a.map(_ + 5)
> 
> if it is a tuple then
> 
>   a.map(x => f(x._1, x._2))
> 
> or you can pass in a function block (with pattern matching case)
> 
>   a.map { case (x, y) => (y, x) }
> 
> there might be some mathematical reason behind the “in” keyword - but it is 
> lost on me as well (it has been a good 30 years since University) and gets 
> lost on me.  If I had more time I might get use to it.
> 
> I hope I did not mess up those examples as bad.
> 
> 
>  
> 
>> On 2015-12-23, at 9:52:46, Andrey Tarantsov > > wrote:
>> 
>>> foo.map( bar => bar.boz) // single line
>> 
>> Well how important is it to use () instead of {} here?
>> 
>> If you make it
>> 
>> foo.map { bar => bar.boz }
>> 
>> then it's like it is now, but with "in" replace by "=>".
>> 
>>> foo.map { (x, y) => x * 5 + y }
>> 
>> I actually like the bare version:
>> 
>> foo.map { x, y => x * 5 + y }
>> 
>> but not in your example (here it looks atrocious). Take this real code, 
>> though:
>> 
>> 
>> constrain(topBlock, tableView, view) { top, tbl, sup in
>> top.left  == sup.left + horizPadding
>> top.right == sup.right - horizPadding
>> top.top   == sup.top  + topPadding
>> 
>> tbl.top== top.bottom + 16
>> tbl.bottom == sup.bottom
>> 
>> tbl.left  == sup.left + horizPadding - horizTableHang
>> tbl.right == sup.right - horizPadding + horizTableHang
>> }
>> 
>> I think the lack of parens is beneficial in reducing the visual noise here.
>> 
>>> And yes, I certainly would prefer `=>` rather than `in`.
>> 
>> It seems like the community can actually agree on this.
>> 
>> Does anyone know if it has any parsing problems / grammar implications right 
>> now? 
>> 
>>> I think a big problem with `in` is that it’s textual, and doesn’t provide a 
>>> clear visual separation from keywords/names at the start of the body or the 
>>> end of the type specifier.
>> 
>> Yes, agreed. “Not delimited enough”.
>> 
>>> (Are the [parentheses] around `bar` in your example required? I’m 
>>> ambivalent to them.)
>> 
>> No, they are not, as shown above.
>> 
>>> To be clear, I’m still not a fan of the Ruby syntax. I think it makes the 
>>> parsing easier for a compiler but harder for a human…
>> 
>> Depends on the human. To this specific human, the Ruby-style one is the 
>> easiest to parse (and mind you, I had very limited experience with Ruby 
>> compared to other languages, so it's not just being used to it, but rather 
>> an honest love and preference).
>> 
>> A.
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Jordan Rose via swift-evolution]

Hi, Alexander. For your most recent version, what does the syntax look like 
when there are explicit types? As far as I can tell the only change is 
substituting "in" for "=>", which means taking an existing keyword (from 'for' 
loops) and replacing it with what's currently a valid operator.

We definitely thought a lot about closure syntax; what we ended up with
(a) is concise,
(b) has some precedent, structurally (Ruby, Smalltalk),
(c) is easy to parse (does not require unbounded lookahead) and therefore 
easier to produce diagnostics for, and
(d) kept the parameter list and return values looking like they do in 
declarations (when types are included)

It may not be the prettiest thing in the language, but I'm not sure why any of 
your proposals are objectively better. The main thing we are missing is that 
closures do not look like standalone function declarations, but we decided that 
they're important enough that they need a lightweight syntax. (Compare with 
JavaScript for a language that did not prioritize this.)

I personally love trailing closures, both here and in Ruby, so I'd put that 
down to just as much a matter of opinion as closure syntax.

Best,
Jordan


> On Dec 22, 2015, at 19:48 , Alexander Regueiro via swift-evolution 
>  wrote:
> 
> The standard map syntax is directly inspired by that of C#.
> 
> For Swift, I’d be relatively happy with something like the following 
> (repeating what’s already been said I believe)
> 
> map ({ x => x + 5 })
> 
> or using trailing closure
> 
> map { x => x + 5 }
> 
> with the possibility of an additional single-line option:
> 
> map ( x => x + 5 )
> 
> (which is useful in the case of non-trailing-closure expressions).
> 
> Of course, I’d rather remove trailing closures altogether, but I suspect that 
> won’t happen. :(
> 
>> On 23 Dec 2015, at 03:45, Craig Cruden > > wrote:
>> 
>> It has probably been 6 months since I have had time to do anything 
>> interesting (JDK6 + Oracle SQL recently for contracts recently) so if I am 
>> messing up terminology or syntax - please excuse me.  I messed a few things 
>> up and had to open up an old Scala project to remind me what I was doing.
>> 
>> 
>> The standard map syntax for Scala is:
>> 
>>  a.map(x => x + 5)
>> 
>> or using a placeholder (very limited shorthand - cannot use a placeholder 
>> twice for the same value):
>> 
>>  a.map(_ + 5)
>> 
>> if it is a tuple then
>> 
>>  a.map(x => f(x._1, x._2))
>> 
>> or you can pass in a function block (with pattern matching case)
>> 
>>  a.map { case (x, y) => (y, x) }
>> 
>> there might be some mathematical reason behind the “in” keyword - but it is 
>> lost on me as well (it has been a good 30 years since University) and gets 
>> lost on me.  If I had more time I might get use to it.
>> 
>> I hope I did not mess up those examples as bad.
>> 
>> 
>>  
>> 
>>> On 2015-12-23, at 9:52:46, Andrey Tarantsov >> > wrote:
>>> 
 foo.map( bar => bar.boz) // single line
>>> 
>>> Well how important is it to use () instead of {} here?
>>> 
>>> If you make it
>>> 
>>> foo.map { bar => bar.boz }
>>> 
>>> then it's like it is now, but with "in" replace by "=>".
>>> 
 foo.map { (x, y) => x * 5 + y }
>>> 
>>> I actually like the bare version:
>>> 
>>> foo.map { x, y => x * 5 + y }
>>> 
>>> but not in your example (here it looks atrocious). Take this real code, 
>>> though:
>>> 
>>> 
>>> constrain(topBlock, tableView, view) { top, tbl, sup in
>>> top.left  == sup.left + horizPadding
>>> top.right == sup.right - horizPadding
>>> top.top   == sup.top  + topPadding
>>> 
>>> tbl.top== top.bottom + 16
>>> tbl.bottom == sup.bottom
>>> 
>>> tbl.left  == sup.left + horizPadding - horizTableHang
>>> tbl.right == sup.right - horizPadding + horizTableHang
>>> }
>>> 
>>> I think the lack of parens is beneficial in reducing the visual noise here.
>>> 
 And yes, I certainly would prefer `=>` rather than `in`.
>>> 
>>> It seems like the community can actually agree on this.
>>> 
>>> Does anyone know if it has any parsing problems / grammar implications 
>>> right now? 
>>> 
 I think a big problem with `in` is that it’s textual, and doesn’t provide 
 a clear visual separation from keywords/names at the start of the body or 
 the end of the type specifier.
>>> 
>>> Yes, agreed. “Not delimited enough”.
>>> 
 (Are the [parentheses] around `bar` in your example required? I’m 
 ambivalent to them.)
>>> 
>>> No, they are not, as shown above.
>>> 
 To be clear, I’m still not a fan of the Ruby syntax. I think it makes the 
 parsing easier for a compiler but harder for a human…
>>> 
>>> Depends on the human. To this specific human, the Ruby-style one is the 
>>> easiest to parse (and mind you, I had very limited experience 

Re: [swift-evolution] Lambda function syntax

[Charles Constant via swift-evolution]

When I started using Swift, and wanted to learn the syntax for closures, I
found the "in" token very confusing. I probably would have figured it out
at least a half hour sooner, if it had been a different word, or an
operator. I kept thinking "that can't be right, I must be misinterpreting
the documentation"

Once you learn the syntax once, it's not a practical issue ever again.
Still, it's kinder to new learners, and reads better, if the syntax uses
something other than "in"


On Tue, Dec 22, 2015 at 1:54 AM, Daniel Valls Estella via swift-evolution <
swift-evolution@swift.org> wrote:

> Just to add my point of view as language user. I don’t know so much about
> compilers and neither have many familiarity with language grammars. I like
> to  learn, and this list helps.
>
> I think clousures are strangely written and break some coherence. I agree
> with Alexander on that.
> But I don’t like the proposed solution.
>
> In the other side, I think trailing closures are a really a great feature,
> I like a lot.
> But I feel it’s a bit confusing in some way, as Alexander pointed. As if
> it was the body definition of the called function.
>
> To throw an idea, the *with* keyword:
>
>
> with (  *parameters* ) -> *return_type* {
> *statements*
> }
>
>
> sorted = names.sort( *with*(s1: String, s2: String) -> Bool {
> return s1 > s2
> })
>
>
> sorted = names.sort( *with*(s1, s2){  return s1 > s2 } )
>
>
> reversed = names.sort( *with*(s1, s2){ s1 > s2 } )
>
>
> reversed = names.sort( { $0 > $1 } )
> OR? reversed = names.sort( *with*{ $0 > $1 } )
>
>
> reversed = names.sort(>)
> OR? reversed = names.sort(*with* >)
>
>
> reversed = names.sort()  *with* { $0 > $1 }   // I think clarifies it is
> an input to exeute not a definition
>
>
> reversed = names.sort *with* { $0 > $1 }  // I think clarifies it is an
> input to exeute not a definition
>
>
> Thanks!
>
>
> Daniel
>
>
> Daniel Valls Estella · tel. 659.910.830 · dan...@upzzle.com
>
> El 22 des 2015, a les 7:57, Thorsten Seitz via swift-evolution <
> swift-evolution@swift.org> va escriure:
>
> Well, I'm actually happy with the current closure syntax as it allows very
> succinct simple cases and trailing closures as Chris has already pointed
> out.
>
> Am 21.12.2015 um 23:44 schrieb Alexander Regueiro via swift-evolution <
> swift-evolution@swift.org>:
>
> Okay, I assume you are aware this essentially the same syntax as used in
> languages like C# and Python, yes? I’m not sure there are any problems in
> those languages with it.
>
> If you dig through (very early) history you’ll see that we had this.
> There are a couple of problems with it:
>
> 1) It punishes simple cases like “X.sort { $1 < $0 }”, along with lots of
> simple map and filter closures.
>
>
> Not really. The above example would just be `X.sort func { $1 < $0 }” or
> "X.sort \ { $1 < $0 }` in my proposed syntax. Also, it would be nice to
> have all operators implicitly
>
>
> Having "func" or the backslash crammed in there is really ugly and
> unreadable IMHO.
>
> And in Haskell you don't have braces for the body to begin with and you
> would have to enclose the closure in parenthesis if it is part of an
> expression like your examples so in effect it would look quite similar,
> i.e. having the parameters within the parenthesis (sure, the semantics are
> different, but I made argument just to demonstrate that what looks good in
> one syntactic environment might not look good in another).
>
> 2) It reads really weird in trailing closure cases.
>
>
> Honestly, I strongly dislike trailing closures. I don’t think they add
> much, and moreover they use a confusing syntax that make the whole function
> call look superficially like a function declaration (or indeed the whole
> thing being a closure).
>
>
> Trailing closures are a great feature IMHO because they make the code much
> more readable by allowing constructs to look similar to control flow
> statements.
> This allows creating very readable DSLs.
>
>
> Lets step back: What problems are you trying to solve with the current
> closure syntax?
>
>
> Readability, mainly. I think this is a big improvement.
>
>
> Well, I think it's the opposite for the simple cases and for trailing
> closures.
>
>
> Then there’s similarity with other languages, which is minor, but nice. I
> don’t know any language that uses a syntax like the current one of Swift.
>
>
> Smalltalk and Ruby immediately come to mind and I'm sure there are others.
>
> Scala has a trailing closure syntax which is similar to Swift's syntax as
> well.
>
> -Thorsten
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list

Re: [swift-evolution] Lambda function syntax

[Ricardo Parada via swift-evolution]

I think "in" is slightly easier to type in than "=>". 
The => may be interpreted as equal or greater than.


On Dec 22, 2015, at 9:52 PM, Andrey Tarantsov via swift-evolution 
 wrote:

>> And yes, I certainly would prefer `=>` rather than `in`.
> 
> It seems like the community can actually agree on this.
> 
> Does anyone know if it has any parsing problems / grammar implications right 
> now? 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Chris Lattner via swift-evolution]

> On Dec 21, 2015, at 11:20 AM, Alexander Regueiro via swift-evolution 
>  wrote:
> 
> Does anyone not like the current syntax for this?
> 
> I would propose changing it from:
> 
> { (param_list) -> return_type in … }
> 
> to something cleaner like:
> 
> (param_list) -> return_type => { … }
> 
> where I’m not so bothered about the `=>` separator (could be `:`, `,`, or 
> indeed `in`).
> 
> The braces being around the type specifier as well as function body rather 
> bothers me. Surely it would be more consistent just to have the braces around 
> the function body, and then the type specifier preceding this?

Hi Alexander,

We’re open in principle to replacing closure syntax with something better, but 
A) it needs to be actually better, and B) it needs to fit with the swift 
grammar.  If you’re interested in pushing forward in this area, please 
familiarize yourself with the structure of the grammar and propose what you’re 
thinking in terms of a diff to it.  Thanks,

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Tino Heth via swift-evolution]

>  am open to whether the introducing keyword is “func” (overloading the 
> existing keyword but in an evidently separate context, and unambiguously I 
> believe) – or “lambda” (like Python), or “\” (like Haskell) – or even 
> something like “cl” (for Closure).
The cool thing with Swift compared to other languages:
Apple could leave out surrogates and just change the key bindings for λ ;-)

Me to had some instinctive repulsion against putting arguments inside the curly 
braces, but it has benefits, and I bet it would be tough to change such a 
fundamental part of the language now
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Chris Lattner via swift-evolution]

> On Dec 21, 2015, at 1:33 PM, Alexander Regueiro  wrote:
> 
> Hi Chris,
> 
> Don’t you think the suggestion is better? I’m happy to formula it in terms of 
> an E(BNF) grammar if you like. Is this published/available anywhere, for the 
> current version of Swift?

My personal opinion is “no”, because it will look very weird in trailing 
closure, in the argument lists for function calls, etc.

Further, it would not permit dropping ()’s on closure arguments, you wouldn’t 
be able to write this:

foo({ lhs, rhs in … })

because the  comma would be exposed out to the function call.

The grammar is described in the reference section of TSPL:
https://swift.org/documentation/

In addition to proposing EBNF, please consider the existing grammar so that the 
new proposal isn’t completely ambiguous.  What you are proposing would be an 
extremely tricky thing to do.

-Chris


> 
> Thanks.
> 
>> On 21 Dec 2015, at 19:22, Chris Lattner  wrote:
>> 
>>> 
>>> On Dec 21, 2015, at 11:20 AM, Alexander Regueiro via swift-evolution 
>>>  wrote:
>>> 
>>> Does anyone not like the current syntax for this?
>>> 
>>> I would propose changing it from:
>>> 
>>> { (param_list) -> return_type in … }
>>> 
>>> to something cleaner like:
>>> 
>>> (param_list) -> return_type => { … }
>>> 
>>> where I’m not so bothered about the `=>` separator (could be `:`, `,`, or 
>>> indeed `in`).
>>> 
>>> The braces being around the type specifier as well as function body rather 
>>> bothers me. Surely it would be more consistent just to have the braces 
>>> around the function body, and then the type specifier preceding this?
>> 
>> Hi Alexander,
>> 
>> We’re open in principle to replacing closure syntax with something better, 
>> but A) it needs to be actually better, and B) it needs to fit with the swift 
>> grammar.  If you’re interested in pushing forward in this area, please 
>> familiarize yourself with the structure of the grammar and propose what 
>> you’re thinking in terms of a diff to it.  Thanks,
>> 
>> -Chris
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Chris Lattner via swift-evolution]

> On Dec 21, 2015, at 2:44 PM, Alexander Regueiro  wrote:
> 
> Okay, I assume you are aware this essentially the same syntax as used in 
> languages like C# and Python, yes? I’m not sure there are any problems in 
> those languages with it.
> 
>> If you dig through (very early) history you’ll see that we had this.  There 
>> are a couple of problems with it:
>> 
>> 1) It punishes simple cases like “X.sort { $1 < $0 }”, along with lots of 
>> simple map and filter closures.
> 
> Not really. The above example would just be `X.sort func { $1 < $0 }” or 
> "X.sort \ { $1 < $0 }` in my proposed syntax. Also, it would be nice to have 
> all operators implicitly convertible to functions, or at the very least have 
> corresponding function definitions for all built-in & standard library 
> operators. Haskell does this really nicely (functions and operators are 
> basically interchangeable, and either can be used in prefix or infix mode). 
> Anyway, your above example might look something like `X.sort (>)` (since 
> `(<)` would take arguments in the opposite order).

Swift already supports this.  X.sort(>) works fine today.  I don’t think that 
that detracts from the point, since there are lots of other simple closures :-)

> 
>> 2) It reads really weird in trailing closure cases.
> 
> Honestly, I strongly dislike trailing closures. I don’t think they add much, 
> and moreover they use a confusing syntax that make the whole function call 
> look superficially like a function declaration (or indeed the whole thing 
> being a closure).

Ok, but you’re going to have to grapple with the fact that they are an 
important aspect of swift design.  If you want your proposal to be seriously 
considered, it needs to consider them.

>> Lets step back: What problems are you trying to solve with the current 
>> closure syntax?
> 
> Readability, mainly. I think this is a big improvement. Also, consistency of 
> semantics. Everything else between curly braces represents a list of 
> statements and is conceptually the “body” of something (a function, a 
> conditional, a loop). The current closure syntax rather embeds the head into 
> the body! Then there’s similarity with other languages, which is minor, but 
> nice. I don’t know any language that uses a syntax like the current one of 
> Swift.

Since your recent proposal has serious tradeoffs, you should explain how each 
of the changes it forces measures on this.

Further, keep in mind that swift supports nested functions, which yield a very 
similar experience to what you’re proposing.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

Thanks for clarifying.

In that case, I would propose grammar for capture expressions, which should 
drop in without modifications elsewhere (I say tentatively):

 closure-expression → “func" closure-signature_opt { statements }
‌ closure-signature → parameter-clause function-result_opt
‌ closure-signature → identifier-list function-result_opt
‌ closure-signature → capture-list parameter-clause function-result_opt
‌ closure-signature → capture-list identifier-list function-result_opt
‌ closure-signature → capture-list
‌ capture-list → [ capture-list-items ]
‌ capture-list-items → capture-list-item | capture-list-item , 
capture-list-items
‌ capture-list-item → capture-specifier_opt expression
‌ capture-specifier → weak | unowned | unowned(safe) | unowned(unsafe)

I am open to whether the introducing keyword is “func” (overloading the 
existing keyword but in an evidently separate context, and unambiguously I 
believe) – or “lambda” (like Python), or “\” (like Haskell) – or even something 
like “cl” (for Closure). Note that the aforementioned adds an additional 
keyword, but also removes the the “in” keyword. For reasons mentioned in my 
previous message, I believe this syntax is both clearer and more consistent. 
It’s also more in line with other widespread languages (in my experience).

For reference, the current grammar is:

 closure-expression → { closure-signature_opt statements }
‌ closure-signature → parameter-clause function-result_opt “in"
‌ closure-signature → identifier-list function-result_opt “in"
‌ closure-signature → capture-list parameter-clause function-result_opt “in"
‌ closure-signature → capture-list identifier-list function-result_opt "in"
‌ closure-signature → capture-list “in"
‌ capture-list → [ capture-list-items ]
‌ capture-list-items → capture-list-item | capture-list-item , 
capture-list-items
‌ capture-list-item → capture-specifier_opt expression
‌ capture-specifier → weak | unowned | unowned(safe) | unowned(unsafe)

Also, I didn’t bother making braces optional, since I hear that the original 
language designers wanted to avoid the problems that optional braces have the 
potential to introduce (e.g. in C-style languages). There are no round brackets 
used in my above syntax either, which is consistent with their absence in 
expressions in conditional and loop statements.

Thoughts?

> On 21 Dec 2015, at 21:47, Chris Lattner  wrote:
> 
> 
>> On Dec 21, 2015, at 1:33 PM, Alexander Regueiro  wrote:
>> 
>> Hi Chris,
>> 
>> Don’t you think the suggestion is better? I’m happy to formula it in terms 
>> of an E(BNF) grammar if you like. Is this published/available anywhere, for 
>> the current version of Swift?
> 
> My personal opinion is “no”, because it will look very weird in trailing 
> closure, in the argument lists for function calls, etc.
> 
> Further, it would not permit dropping ()’s on closure arguments, you wouldn’t 
> be able to write this:
> 
> foo({ lhs, rhs in … })
> 
> because the  comma would be exposed out to the function call.
> 
> The grammar is described in the reference section of TSPL:
> https://swift.org/documentation/
> 
> In addition to proposing EBNF, please consider the existing grammar so that 
> the new proposal isn’t completely ambiguous.  What you are proposing would be 
> an extremely tricky thing to do.
> 
> -Chris
> 
> 
>> 
>> Thanks.
>> 
>>> On 21 Dec 2015, at 19:22, Chris Lattner  wrote:
>>> 
 
 On Dec 21, 2015, at 11:20 AM, Alexander Regueiro via swift-evolution 
  wrote:
 
 Does anyone not like the current syntax for this?
 
 I would propose changing it from:
 
 { (param_list) -> return_type in … }
 
 to something cleaner like:
 
 (param_list) -> return_type => { … }
 
 where I’m not so bothered about the `=>` separator (could be `:`, `,`, or 
 indeed `in`).
 
 The braces being around the type specifier as well as function body rather 
 bothers me. Surely it would be more consistent just to have the braces 
 around the function body, and then the type specifier preceding this?
>>> 
>>> Hi Alexander,
>>> 
>>> We’re open in principle to replacing closure syntax with something better, 
>>> but A) it needs to be actually better, and B) it needs to fit with the 
>>> swift grammar.  If you’re interested in pushing forward in this area, 
>>> please familiarize yourself with the structure of the grammar and propose 
>>> what you’re thinking in terms of a diff to it.  Thanks,
>>> 
>>> -Chris
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Chris Lattner via swift-evolution]

On Dec 21, 2015, at 2:26 PM, Alexander Regueiro  wrote:
> Thanks for clarifying.
> 
> In that case, I would propose grammar for capture expressions, which should 
> drop in without modifications elsewhere (I say tentatively):
> 
> closure-expression → “func" closure-signature_opt { statements }

If you dig through (very early) history you’ll see that we had this.  There are 
a couple of problems with it:

1) It punishes simple cases like “X.sort { $1 < $0 }”, along with lots of 
simple map and filter closures.
2) It reads really weird in trailing closure cases.

Lets step back: What problems are you trying to solve with the current closure 
syntax?

-Chris



> ‌ closure-signature → parameter-clause function-result_opt
> ‌ closure-signature → identifier-list function-result_opt
> ‌ closure-signature → capture-list parameter-clause function-result_opt
> ‌ closure-signature → capture-list identifier-list function-result_opt
> ‌ closure-signature → capture-list
> ‌ capture-list → [ capture-list-items ]
> ‌ capture-list-items → capture-list-item | capture-list-item , 
> capture-list-items
> ‌ capture-list-item → capture-specifier_opt expression
> ‌ capture-specifier → weak | unowned | unowned(safe) | unowned(unsafe)
> 
> I am open to whether the introducing keyword is “func” (overloading the 
> existing keyword but in an evidently separate context, and unambiguously I 
> believe) – or “lambda” (like Python), or “\” (like Haskell) – or even 
> something like “cl” (for Closure). Note that the aforementioned adds an 
> additional keyword, but also removes the the “in” keyword. For reasons 
> mentioned in my previous message, I believe this syntax is both clearer and 
> more consistent. It’s also more in line with other widespread languages (in 
> my experience).
> 
> For reference, the current grammar is:
> 
> closure-expression → { closure-signature_opt statements }
> ‌ closure-signature → parameter-clause function-result_opt “in"
> ‌ closure-signature → identifier-list function-result_opt “in"
> ‌ closure-signature → capture-list parameter-clause function-result_opt “in"
> ‌ closure-signature → capture-list identifier-list function-result_opt "in"
> ‌ closure-signature → capture-list “in"
> ‌ capture-list → [ capture-list-items ]
> ‌ capture-list-items → capture-list-item | capture-list-item , 
> capture-list-items
> ‌ capture-list-item → capture-specifier_opt expression
> ‌ capture-specifier → weak | unowned | unowned(safe) | unowned(unsafe)
> 
> Also, I didn’t bother making braces optional, since I hear that the original 
> language designers wanted to avoid the problems that optional braces have the 
> potential to introduce (e.g. in C-style languages). There are no round 
> brackets used in my above syntax either, which is consistent with their 
> absence in expressions in conditional and loop statements.
> 
> Thoughts?
> 
>> On 21 Dec 2015, at 21:47, Chris Lattner  wrote:
>> 
>> 
>>> On Dec 21, 2015, at 1:33 PM, Alexander Regueiro  wrote:
>>> 
>>> Hi Chris,
>>> 
>>> Don’t you think the suggestion is better? I’m happy to formula it in terms 
>>> of an E(BNF) grammar if you like. Is this published/available anywhere, for 
>>> the current version of Swift?
>> 
>> My personal opinion is “no”, because it will look very weird in trailing 
>> closure, in the argument lists for function calls, etc.
>> 
>> Further, it would not permit dropping ()’s on closure arguments, you 
>> wouldn’t be able to write this:
>> 
>> foo({ lhs, rhs in … })
>> 
>> because the  comma would be exposed out to the function call.
>> 
>> The grammar is described in the reference section of TSPL:
>> https://swift.org/documentation/
>> 
>> In addition to proposing EBNF, please consider the existing grammar so that 
>> the new proposal isn’t completely ambiguous.  What you are proposing would 
>> be an extremely tricky thing to do.
>> 
>> -Chris
>> 
>> 
>>> 
>>> Thanks.
>>> 
 On 21 Dec 2015, at 19:22, Chris Lattner  wrote:
 
> 
> On Dec 21, 2015, at 11:20 AM, Alexander Regueiro via swift-evolution 
>  wrote:
> 
> Does anyone not like the current syntax for this?
> 
> I would propose changing it from:
> 
> { (param_list) -> return_type in … }
> 
> to something cleaner like:
> 
> (param_list) -> return_type => { … }
> 
> where I’m not so bothered about the `=>` separator (could be `:`, `,`, or 
> indeed `in`).
> 
> The braces being around the type specifier as well as function body 
> rather bothers me. Surely it would be more consistent just to have the 
> braces around the function body, and then the type specifier preceding 
> this?
 
 Hi Alexander,
 
 We’re open in principle to replacing closure syntax with something better, 
 but A) it needs to be actually better, and B) it needs to fit with the 
 swift grammar.  If 

Re: [swift-evolution] Lambda function syntax

[Alexander Regueiro via swift-evolution]

Okay, I assume you are aware this essentially the same syntax as used in 
languages like C# and Python, yes? I’m not sure there are any problems in those 
languages with it.

> If you dig through (very early) history you’ll see that we had this.  There 
> are a couple of problems with it:
> 
> 1) It punishes simple cases like “X.sort { $1 < $0 }”, along with lots of 
> simple map and filter closures.

Not really. The above example would just be `X.sort func { $1 < $0 }” or 
"X.sort \ { $1 < $0 }` in my proposed syntax. Also, it would be nice to have 
all operators implicitly convertible to functions, or at the very least have 
corresponding function definitions for all built-in & standard library 
operators. Haskell does this really nicely (functions and operators are 
basically interchangeable, and either can be used in prefix or infix mode). 
Anyway, your above example might look something like `X.sort (>)` (since `(<)` 
would take arguments in the opposite order).

> 2) It reads really weird in trailing closure cases.

Honestly, I strongly dislike trailing closures. I don’t think they add much, 
and moreover they use a confusing syntax that make the whole function call look 
superficially like a function declaration (or indeed the whole thing being a 
closure).

> Lets step back: What problems are you trying to solve with the current 
> closure syntax?

Readability, mainly. I think this is a big improvement. Also, consistency of 
semantics. Everything else between curly braces represents a list of statements 
and is conceptually the “body” of something (a function, a conditional, a 
loop). The current closure syntax rather embeds the head into the body! Then 
there’s similarity with other languages, which is minor, but nice. I don’t know 
any language that uses a syntax like the current one of Swift.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Lambda function syntax

[Thorsten Seitz via swift-evolution]

Well, I'm actually happy with the current closure syntax as it allows very 
succinct simple cases and trailing closures as Chris has already pointed out.

> Am 21.12.2015 um 23:44 schrieb Alexander Regueiro via swift-evolution 
> :
> 
> Okay, I assume you are aware this essentially the same syntax as used in 
> languages like C# and Python, yes? I’m not sure there are any problems in 
> those languages with it.
> 
>> If you dig through (very early) history you’ll see that we had this.  There 
>> are a couple of problems with it:
>> 
>> 1) It punishes simple cases like “X.sort { $1 < $0 }”, along with lots of 
>> simple map and filter closures.
> 
> Not really. The above example would just be `X.sort func { $1 < $0 }” or 
> "X.sort \ { $1 < $0 }` in my proposed syntax. Also, it would be nice to have 
> all operators implicitly

Having "func" or the backslash crammed in there is really ugly and unreadable 
IMHO.

And in Haskell you don't have braces for the body to begin with and you would 
have to enclose the closure in parenthesis if it is part of an expression like 
your examples so in effect it would look quite similar, i.e. having the 
parameters within the parenthesis (sure, the semantics are different, but I 
made argument just to demonstrate that what looks good in one syntactic 
environment might not look good in another).

>> 2) It reads really weird in trailing closure cases.
> 
> Honestly, I strongly dislike trailing closures. I don’t think they add much, 
> and moreover they use a confusing syntax that make the whole function call 
> look superficially like a function declaration (or indeed the whole thing 
> being a closure).

Trailing closures are a great feature IMHO because they make the code much more 
readable by allowing constructs to look similar to control flow statements.
This allows creating very readable DSLs.


>> Lets step back: What problems are you trying to solve with the current 
>> closure syntax?
> 
> Readability, mainly. I think this is a big improvement. 

Well, I think it's the opposite for the simple cases and for trailing closures. 


> Then there’s similarity with other languages, which is minor, but nice. I 
> don’t know any language that uses a syntax like the current one of Swift.

Smalltalk and Ruby immediately come to mind and I'm sure there are others.

Scala has a trailing closure syntax which is similar to Swift's syntax as well.

-Thorsten 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution