Tricky case for uncurried by default when `.` appears in non head positions

[bobzhang]

let f = (x, .y, z) => x +y + z

. should be only allowed in the first position (. x , y) => x + y

[mununki]

How about "res.async"?
Worth considering how to handle "bs" and "res.async" respectively.

Maybe we can parse it (x) => (. y, z) => ...?

[mununki]

Had some related exploring rescript-lang/syntax#683

[bobzhang]

The idea is that by reading (, (. you know that the function is curried / uncurried, so that we can toggle the default in the future. cc @cristianoc

[cristianoc]

I think this comment is about what happens in a single parenthesised thing ( ... ) which currently mixes curried and uncurried intentions. Instead, it's more clear if each parenthesised group defines either an uncurried or a curried function, so one can just flip the interpretation later on.

Not sure if disallowing . in non-first position any different than formatting it into first-position as #5792 suggests. If (x, .y, z) => x +y + z parses to the same AST as (x) => (. y, z) => x+y+z does, then effectively it's as if the first syntax did not exist in practice (and will in fact disappear after formatting). I guess experimenting with that parsing, and printing, does not hurt. If it does not work, one still has the option to disallow (x, .y, z) => x +y + z.

[cristianoc]

Added this under the overall uncurried by default issue #5597

[IwanKaramazow]

I recently took care of the printing side in rescript-lang/syntax#668.

Do we have the budget to implement this breaking change right now? (Budget as in release-wise, implementation effort is a 5min change)

[cristianoc]

This seems part of rescript-lang/syntax#683, which is for v11.
Hopefully we don't need to break anything if it can be transformed at parsing time.

[cristianoc]

Actually this let f = (x, .y, z) => x + y + z is already formatted as let f = x => (. y, z) => x + y + z right now.

I think the issue is something else: that (.x) => (y) => 12 becomes (. x, y) => 12, so that's not a way to express the intention of a unary uncurried function returning a curried function.
However, notice instead that (.x) => { y => 12 } stays (.x) => {y => 12}

I thought that the original proposal was only to ban (x, .y, z) => x + y + z, but equally one would have to ban x => (.y) => z => x + y + z.

Assuming this stronger ban is the intention, one could instead:

• parse (x, .y, z) => x + y + z to x => { (.y, z) => x + y + z }, and
• parse x => (.y) => z => x + y + z in the same way.

With that choice, assuming current curried by default mode is C, and the new uncurried by default mode is U, the conversion from C to U would turn (x, .y, z) => x + y + z into (. x) => { (y, z) => x + y + z }.
CC @mattdamon108

[cristianoc]

Similarly, (.x) => (.y) => 3 currently formats to itself, which is problematic when one wants to flip the switch.
Instead, it could be parsed as (.x) => { (.y) => 3 }.

[cristianoc]

There are also some issues one cannot easily get around without telling the parser whether it is in curried or uncurried mode.
For example, when in uncurried mode (x) => (y) => 3 is 2 nested uncurried functions, and one cannot format it to (x, y) => 3.

Without a distinction between uncurried and curried mode, one would have to be safe and format (x) => (y) = 3 to (x) => { (y) => 3 }.

[bobzhang]

I suggest we have a simple and clean semantics of curring/uncurring in the stage as early as possible. Depending on the ppx transformation is not reliable, the formatter is also hard to get it right.

To make the formatter easier to write, here is the encoding I proposed that we should do it in the parsing stage instead of relying on the later transformations.
https://docs.google.com/document/d/1St30rQ2YqzW1M2vAkdrK-qJK-2u-xLutJ1Z4ZfS8g5s/edit

The current workflow is that we parse it as curried call with [@bs] attribute and running ppx transformation to turn it to the encoding mentioned above, my proposal is that parse it directly to the encoding documented as above. The benefit is that the formatter is more robust and honest to our encoding, since it does not rely on the attribute but on a dedicated syntax (record here)

[cristianoc]

Added an issue for this: #5793

[cristianoc]

More tricky cases: https://github.com/rescript-lang/rescript-compiler/pull/5783/files#r1015662047