[swift-evolution] Lambda function syntax

[Charles Constant]

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 at 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 · daniel at upzzle.com
>
> El 22 des 2015, a les 7:57, Thorsten Seitz via swift-evolution <
> swift-evolution at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151222/07a17fed/attachment.html>