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 <and...@tarantsov.com> 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