Syntactic sugar for multi-parameter functions

[Earthcomputer]

trafficstars

Currently, multi-parameter functions have no explicit support in chassembly, but they can be emulated using functions that return functions. For example, here's a function that adds its two inputs:

{
  add: x -> y -> x + y
}

it can be called like this:

add(2)(3)

Although this works, it makes for a lot of parentheses at call sites. One way to improve the situation would be to add syntactic sugar for applying the function:

add(2, 3)

which would be semantically exactly the same as above.

Others have proposed a similar syntax to declarations (I'm personally not sold on this):

{
  add: (x, y) -> x + y
}

this has the disadvantage that it requires increasing the lookahead in the parser to 2.

If we go ahead with the declaration syntax, one possibility is that this will have the same semantics as the arrow declaration. That is, the following functions would be exactly equivalent:

{
  add1: (x, y) -> z -> x + y + z
  add2: x -> (y, z) -> x + y + z
}

Another option is to have the special declaration syntax mean something semantically different: making partial application impossible. Thus, with the above function declarations:

{
  a: add1(x, y, z), // ok
  b: add1(x, y)(z), // ok
  c: add1(x)(y, z), // error
  d: add1(x)(y)(z), // error
}

[CheaterCodes]

I'll preface this with saying that I'd be in favor of implementing both new syntax suggestions.

The concern mentioned with lookahead can safely be ignored. We actually already use a lookahead of 2 in several places, and even if this woul increase to a lookahead of 3, it's not really a problem.

I would probably not assign different behavior to the different syntaxes, although it could prevent some programming errors. However, this type of partial evaluation (I can't remember the correct term) is actually an often wanted feature in (functional) programming.

On a last note, the parantheses around lambda declarations are actually technically unnecessary. It should always unambiguously parse to either a lambda or an identifier folowed by the next map entry.

[Earthcomputer]

On a last note, the parantheses around lambda declarations are actually technically unnecessary. It should always unambiguously parse to either a lambda or an identifier folowed by the next map entry.

That's the case when the lambda is being used in map bodies, but not in other places, such as as a parameter themselves

[CheaterCodes]

Good point