Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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, >

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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 > : >

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

> 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

Re: [swift-evolution] Lambda function syntax

> 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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

> 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

Re: [swift-evolution] Lambda function syntax

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,

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

> 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 =

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

> 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*

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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: > >

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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 {

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

>> 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

Re: [swift-evolution] Lambda function syntax

> 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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

> 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) ->

[swift-evolution] Lambda function syntax

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

Re: [swift-evolution] Lambda function syntax

> 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

Re: [swift-evolution] Lambda function syntax

> 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

Re: [swift-evolution] Lambda function syntax

> 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)

Re: [swift-evolution] Lambda function syntax

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 ‌

Re: [swift-evolution] Lambda function syntax

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"

Re: [swift-evolution] Lambda function syntax

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)

Re: [swift-evolution] Lambda function syntax

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