Explore uncurried by default

[cristianoc]

This issue is about exploring technical changes required to explore how uncurried by default would feel like in practice.

The basic idea is to have an uncurried-by-default mode, to be turned on in some way. Presumably by config to begin with. So that existing projects are not affected and one can turn on by config and start using the new mode. It could be nice to have some support to "convert" between curried and uncurried by default (a syntax change where code is parsed in curried mode and printed in uncurried mode).

• More direct endcoding on uncurry in the ast More direct encoding of uncurried function and type definitions #5793

• Only one equation holds: x => y => 3 is the same as (x, y) => 3. No equation for uncurried holds.

• Expose uncurried by default via configuration: @@uncurried at the file level to begin experimenting. Uncurried mode #5796

• Syntax swap in uncurried mode:

  • The function (x, y) => x+y would be uncurried and (. x, y) => x+y curried.
  • Same for types.
  • Dotted application is curried, and non-dotted is uncurried.
  • Only one equation holds: (. x) => (. y) => 3 is the same as (. x, y) => 3.

• Unify uncurried functions of arity 0, and of arity 1 taking unit. Both (. ()) => 3 and (. (():unit)) => 3 are now functions of arity 1. And foo(.) is the same as {let u = (); foo(. u) }. This means curried code can be pasted as-is in an uncurried mode context. Parser/Printer: unify uncurried functions of arity 0, and of arity 1 taking unit. #5825

• Mixed declarations. The current syntax (x, .y, z) => ... is problematic for flipping the meaning. Work around it. Tricky case for uncurried by default when . appears in non head positions #5792

• Automatic conversion to uncurried via @@toUncurried annotation and reformat Support automatic conversion to uncurried syntax via @@toUncurried and reformat #5800

• JSX assumes the make function is curried JSX V4: allow uncurried make function and treat it as usual #5802

• Currently there's no support for -> and uncurried functions Fix issue where uncurried was not supported with pipe #5803

• In the case of unary functions, there isn't even a syntax corresponding to the curried x->foo Add support for unary uncurried pipe in uncurried mode #5804

• Builtin operators and libraries. The expression x+y uses the curried operator + which is OK as it's inlined during parsing, but things like raise(E) in uncurried mode do not work as raise is curried. Same issue for other libraries. Add support for partial application of uncurried functions #5805

• Optional/default arguments. The critical case is JSX. That is already taken care of in V4. For user space, handle uncurried application in the type checker and clean up uncurried processing for methods and other FFI annotations. Process uncurried application in the type checker. #5835 Remove processing of objects expressions, which don't exist in .res… #5841 Remove class type processing from compiler ppx. #5842 Remove method application via operator ##. #5844 Treat @meth annotation as making the type uncurried. #5845 Process @set annotation for field update as generating an uncurried… #5846

• Externals are curried and use certain internal mechanisms to make them behave as uncurried. Might need special treatment there. Add support for uncurried externals #5815 Uncurried support for externals part 2 #5819 Add support for uncurried @this #5830 Support @uncurry externals with uncurried types. #5894

• Uncurried functions do not inline cleanly, e.g. let v7 = {let id = (. x) => x; id(. 7)} or uses of primitives Inline uncurried application when it is safe #5847 Treat uncurried application of primitives like curried application #5851

• Explore default arguments in uncurried functions without a final unit argument Support optional named arguments without a final unit in uncurried functions. #5907 Fix type inference issue with uncurried functions applied to a single… #5970

[illusionalsagacity]

Syntax swap. The function (x, y) => x+y would be uncurried and (. x, y) => x+y curried.

I could see this swap being confusing if a library does not have the config value flipped and the user is using editor go to definition. I often use that for rescript libraries that do not have documentation websites.

Another idea would be to have the printer re-format if the config value is on:

• (. x, y) => x + y -> (x, y) => x + y
• (x, y) => x + y -> (? x, y) => x + y

where ? is an arbitrary character to indicate a curried function

[mununki]

when V4 is used, only 1 argument is used anyway so it does not really matter whether one uses the uncurried or curried convention

There is one minor exception, forwardRef. https://github.com/rescript-lang/syntax/blob/cbc5e69b5abab3e383c022b0d0f1b1e901a34644/tests/ppx/react/expected/forwardRef.res.txt#L77

[cristianoc]

True but that is super hacky and I'm sure it can be equally hacked for uncurried.

[joakin]

Another idea would be to have the printer re-format if the config value is on:

Some flags to decide how to migrate a codebase would be useful, in case you want to keep all curried definitions syntax and when they become uncurried and deal with any compiler errors manually.

• (. x, y) => x + y -> (x, y) => x + y
• (x, y) => x + y -> (? x, y) => x + y

where ? is an arbitrary character to indicate a curried function

I'm personally against adding even more syntax, it would be nice if it was possible to apply the currying treatment to the normal curried functions like in JS:

• (x, y) => x + y -> x => y => x + y