Better notation to re-use `&`?

[danielxmoore]

Better notation to re-use `&`?

[STRd6]

I think forbidding access to the function variable is probably correct. It just sort of happens to work by chance of implementation currently.

I think in cases where you need to reference the parameter using an explicit arrow function is the simplest and most direct way to do it.

[edemaine]

Sounds good. I think we can turn $ into a Ref to achieve this?

[STRd6]

@edemaine Yes, that should work.

[lorefnon]

I didnt realize something like &+& doesn't work - that is counterintuitive.

For multiarg probably the closest precedent in mainstream langs is swift - which allows $n eg. numbers.reduce(0) { $0 + $1 } which is nice but I too think its not that much better than just having an inline lambda with named args.

[edemaine]

Huh, I was wondering about wrapping & expressions (or some other notation) in braces to indicate where the function wrapper goes (especially for placeholders). But yeah, not much more concise than an arrow function. I guess the nice thing is not having to spend time naming the arguments and not having to repeat them more than once... So I think it still might be interesting to think about.

[lorefnon]

I was wondering about wrapping & expressions (or some other notation) in braces to indicate where the function wrapper goes (especially for placeholders)

Yeah I think most of the ambiguity here is around identifying where the function boundary goes. I propose simply mandating that the function is explicit (similar to my other suggestion in the do discussion)

ie. [1, 2, 3].map(new User id: &) -> [1, 2, 3].map(-> new User id: &)

If this seems too big of a change, then can we separately adopt it as kotlin supports it ? If a function doesn't have any explicit arguments, it gets an implicit argument called it which is the solo argument.

It is also convenient for nested lambdas, because it always comes from the nearest parent function without an explicit argument:

[1, 2, 3].map(-> foo(name -> `name${it}`))

Transpiles to:

[1,2,3].map(function(it) { 
    return foo(function(name) { 
        return `name${it}` 
    })
})

[STRd6]

The $ ref part of this was fixed in 1d9e4d0

[STRd6]

It might not be too hard to get & as a topic reference in places where it is unambiguous. It may require some clever lookaheads in some other situations.

[STRd6]

Just had a thought that maybe we could have a syntax like &. but which creates a new this scope so that @ is the topic reference.

@.something // if we want to force accessors into @something only
---
function(){ return this.something }.call

We could maybe use a different symbol as well.

[STRd6]

Did a quick search of the CoffeeScript codebase and @. appears zero times so it's a good candidate. We could disable it in coffeeCompat as well.

[STRd6]

items.map @\ `${@name}: ${@price}`
animals.forEach @\ console.log 'test' if @name == 'Fluffy'

Seems ok, but still might need to refine the symbol.

[edemaine]

Neat idea! The two issues I see are that it shadows this in the surrounding context (might be annoying in some cases), and that @ already means something when followed by a [, (, or binary op (and . too), so the notation feels limited.

I wonder whether something like { @.foo } could be shorthand for function() { return this.foo }.call? This has the advantage that you can actually specify the block boundary, e.g. { 'hello' + @ } works. The only conflict I know is object literal syntax like { @foo } but I believe that doesn't work with a dot. Oh, no, it does, with the new object literal shorthand. Also { @(5).x.y } is an object literal now I think.