More compact anonymous procs

[def-]

As I wrote in https://github.com/Araq/Nim/pull/2175 already:

It's also quite unfortunate that we even need the mapIt and related templates. Would be much nicer if instead we could do .map(x => x.lastName) instead of the more unwiedy .map((x: User) -> string => x.lastName).

[flaviut]

Scala's approach here is .map(_.lastName), which I'm a big fan of.

It's smaller than the unwieldy .map(x => x.lastName) :wink:

[def-]

But the approach with _ isn't as nice when you have multiple arguments, while x, y => x.lastName & y would still be nice.

[bluenote10]

+1 for more compact anonymous procs in general. In fact, this is the only feature that I'm really missing in Nim at the moment.

I also like Scala's underscore syntax a lot, and expressions like collection.reduce(_ + _) or collection.sortBy(_.age < _.age) are in my opinion pretty clear. The rule is simply: If you have to use a parameter multiple times you have to give it a name, otherwise you can use underscore syntax.

But to be clear: The important point here is to get rid of type annotations in the first place, which would make writing anonymous functions already much more practical. The underscore syntax is nice to have, but the additional benefit is limited (often 5 characters).

[ozra]

flabiut, bluenote10: Agree on the _ notation - I'm used to similar shorthand from other langs.

In Kdb/Q, there's auto-parameterization fn's (I've tried emuating it with macro for fun, limited success) where non-parameterized auto-fns gets it's used symbols in the body automatically put into a param. They are taken in a pre-decided order. x, y, z... - x goes first, no matter in what order they're used in the body. This might seem a bit funky, and all in all, I think the mentioned approach of (_ < _) where 'single-use' is unambiguous and otherwise formal params must be used is cleaner.

And yes, +1 on ridding it of having to annotate types!

[refi64]

@ozra K is a wildly different beast, though. It's also dynamic...

Whole program type inference is possible: look at Crystal. However, the error messages can be very odd at times. Maybe parameter type inference could be added "as a nice RAD idea to never be used in production code.

However, +1 for anonymous functions without types. That's a little easier (I think?) and can have less weird consequences.

[Araq]

This works since quite some time now:

import future, sequtils

type
  Obj = object
    lastName: string

var s: seq[Obj]
echo s.map(x => x.lastName)