feat(compiler)!: Partial function application

[alex-snezhko]

Partial function application

let add = (x, y) => x + y
let add1 = partial add(1, _)
assert add1(2) == 3

let printValues = (x, y, z=3) => {
  print(x)
  print(y)
  print(z)
}
let printSome = partial printValues(y=2, _, z=_)
printSome(1) // prints 1, 2, 3

Closes #402

[alex-snezhko]

TODO:

• Make precedence of partial tighter to allow x |> partial add(_, y) without parentheses around the partial expression
• Decide if this feature should be supported for infix functions - doesn't seem particularly useful so will not do in this PR

[alex-snezhko]

This was kind of a bandaid fix around me being a noob with LR(1) parsers and not being able to figure out how to create separate rules for partial and total applications without reduce/reduce conflicts. If anyone has insight on how to do this please let me know

[ospencer]

Marked this as breaking because of the new keywords.

[spotandjake]

I had a few questions mostly on the dummy locations, looks great overall though.

[spotandjake]

Should we point to the arg.ppaa_loc? I feel like this error might be a little annoying as it isn't immediately clear that the _ hole is specific to partial application, at least that way the position would be telling you hey this argument is the issue specifically, an alternate here would be Hole patterns are only allowed under partial application, prefix the function call with partial. which is a bit more specific and searchable.

[spotandjake]

Can we give all this stuff the location from the arg.

[spotandjake]

Should this take the location from the func?

[spotandjake]

Same as above.

[spotandjake]

Should this take the location from ty?

[spotandjake]

as a sanity check can we just add a print("0") between the partial application and the actual application of the function i think it's obvious that it will only call the function afterwards but I feel like we should still double check that.

[spotandjake]

Should we have a test where a module provides a partially applied function, also maybe a clear test where a function returns a partially applied function. something like:

let f = (x, y) => {
  let t  = (a, b) => x + a + b
  let y = partial (_, y)
  y
}
print(f(1, 2)(3)) // 6

this ensures that we don't break closures and ensures that we are not losing the partial information when returning from a scope (The way this is implemented I don't think those are major concerns but they seem like good sanity checks. I think your test with the pipeline operator somewhat tests this but doesn't test closures.

[spotandjake]

I was having a little trouble visualizing what is actually happening here are we building a tuple from the arguments and then passing the tuple around and at the end passing the tuple values to the function when its fully applied? or did I misunderstand the abstraction here?

[spotandjake]

Should we add this function to pervasives? I feel like the moment we add partial application we are going to be asked for a pipeline operator soon after we add this.