& function shorthand improvements

[edemaine]

Currently, the rule is: unary operators to the left of, and everything to the right of, a & symbol get wrapped into the function.

The proposal (from Discord discussion on March 1) is to make & "go up a level" if there's nothing right before or after it, namely, when it's followed by a comma or closing bracket. Examples:

f(a, &, b)    →  $ => f(a, $, b)
console.log & →  $ => console.log($)
& |> f |> g   →  $ => g(f($))      — already implemented
[&, x]        →  $ => [$, x]
{text: &}     →  $ => {text: $}
{&: "value"}  →  $ => {[$]: "value"}
x.filter !Array.isArray &
              →  x.filter($ => !Array.isArray($))
x > &         →  $ => x > &

None of these parse currently (except for the one already implemented).

I think we need to precisely define "go up a level", but I guess I'm imagining until a level of brackets or a function call, but also preceding unary operators and maybe stuff trailing the function call.

We also lack a notation for $ => $, which is occasionally useful (e.g. for filter). With this notation, (&) would still work well. Dealt with in #635.

Related: #75 (essentially partials; cf. % for generic pipe placeholder), and various proposals for & escaping another level up (e.g. ((&)))

[STRd6]

One challenge is the interaction with existing & shorthand is some positions:

x:
  a: &
  b: & + 1

// Ex. 1
({x: {
  a: $ => $,
  b: $ => $ + 1
}})
// Ex. 2
$ => ({x: {
  a: $,
  b: $ + 1
}})

It seems like unwrapping the same level shorthands makes sense and is generally what would be expected (Ex. 2). It does however make passing sibling functions challenging in other circumstances.

Just wanted to note this so we can figure out the edge cases.

[edemaine]

Good point. Alternate parses for that same example:

// Ex. 3
{x: $ => {
  a: $,
  b: $ => $ + 1
}}
// Ex. 4
{x: $ => {
  a: $,
  b: $ + 1
}}

I realize this is also related to #85. If we end up with Ex. 2 or Ex. 4, we should reconsider whether &+& should in fact parse to $ => $+$. But as you say, we need to take care with shorthand functions contained in or sibling to other shorthand functions.

[juh9870]

And this is how that example parsed by web playground:

({
  x: {
    a: ($) =>
      $({
        b: ($1) => $1 + 1,
      }),
  },
});

[gwhitney]

Presumably the recently-added x > & case would also cover other operators like 3 - & or test ? & : null. Except wait a minute & ? trueVal : falseVal doesn't even parse right now, even though it would seem to be OK from the current rule of starts with & except for unary operators. So perhaps that's verging on an inconsistency/bug in Civet as it stands? Should I file that observation of ternary operator with & first not working as a separate issue?

[edemaine]

Yes, it seems like we forgot about the ternary. Oops!

[bbrk24]

unary operators to the left

Not even: I tried ++& as a synonym for (1+) and that doesn't parse. ++& % y becomes ++$ => $ % y which is completely invalid JS.

[edemaine]

Replaced by the (now implemented) #1070 which lets & escape all the way to (but not including) a function call or assignment/declaration.