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 <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
