Uncurried always #5968

cristianoc · 2023-02-01T10:10:57Z

Add support for uncurried-always: a special mode where all functions definitions and applications are considered uncurried, ignoring whether . is used.

Added a project config {"uncurried": ...}, which propagates to dependencies, and takes the values: "legacy" which changes nothing, or "default" for uncurried by default, or "always" for uncurried-always mode.
Introduce automatic curried application in uncurried-always mode: when a function with curried type is used in an application, the application is treated as curried application. E.g. Belt.List.map([]) works even though technically the application is uncurried.
Introduce a form of subtyping in uncurried-always mode: uncurried functions are cast to curried ones during unification.
Introduce a fallback mechanism @res.partial to force partial application: @res.partial foo(x, y) is treated as partial application. This is the only way to express partial application of uncurried functions in uncurried-always mode.

For example, existing code could use Js.Array2.map([1], x => x+1). In the new mode, this is an uncurried application, and the callback is a curried function. Both mechanisms are uses, so the application is treated as curried application, and the callback function is cast to an uncurried one.

cristianoc · 2023-02-04T13:20:05Z

@mununki are the changes to support uncurried functions in JSX V4 also possible for V3, or is the new data representation that makes this possible?
Just curious about the answer for now, unclear whether this is something one would want for real legacy code.

mununki · 2023-02-04T15:40:53Z

@mununki are the changes to support uncurried functions in JSX V4 also possible for V3, or is the new data representation that makes this possible? Just curious about the answer for now, unclear whether this is something one would want for real legacy code.

Afraid to say so. I don't think V3 would work with the new data representation introduced by uncurried.
I remember making V4 compatible with the new data representation was kinda simple. I can put the same work on V3 if you think it is needed. Why not make V3 support the uncurried mode?

cknitt · 2023-02-05T14:20:44Z

Just got curious and tried the following:

download the last PR build
install it into one of our projects
build in legacy mode => works fine
set "uncurried": "always" in bsconfig.json and rebuild

This gave me an error here:

type t
let onEvent: ref<t => unit> = ref(ignore)

  Somewhere wanted: ref<(. t) => unit>

  The incompatible parts:
    'a => unit vs (. t) => unit

Is it too early to test with real-world projects?

cristianoc · 2023-02-05T19:45:16Z

Just got curious and tried the following:

download the last PR build

install it into one of our projects

build in legacy mode => works fine

set "uncurried": "always" in bsconfig.json and rebuild

This gave me an error here:
type t
let onEvent: ref<t => unit> = ref(ignore)
 Somewhere wanted: ref<(. t) => unit>

 The incompatible parts:
   'a => unit vs (. t) => unit
Is it too early to test with real-world projects?

This is a good time to start experimenting with projects and see how it goes.
Even though most uses of compiler libs still work, one cannot do magic and have all possible existing code still compile without change.

In this case, ignore, coming from the compiler library, has curried type. And adding it to a reference, gives a reference to a curried function. The annotation, : ref<t => unit>, which is in uncurried-always mode, is interpreted as saying: it's an uncurried type.

In this case you need to wrap let ignore = x => ignore(x) to make ignore an uncurried function.
In general, one could provide a whole special version of the compiler libs, and ignore would be uncurried to begin with. However, that's logistically difficult. So it's interesting to experiment and see how much one needs to manually change (such as re-wrapping ignore in this case).

cristianoc · 2023-02-05T19:47:15Z

As a side note, one cannot promote automatically a curried function to an uncurried one, as that's not a safe transformation. The opposite one, is safe, and automatic cast in that direction is part of this PR.

cknitt · 2023-02-06T06:11:58Z

Understood. I wonder if we need to provide multiple copies of the standard libraries (compiled in different modes)?

Another thing: In "uncurried always" mode,

let make: ('a => unit) => ('a => unit) = x => x

compiles fine, but gets reformatted to

let make: ('a => unit, 'a) => unit = x => x

which does not compile.

cristianoc · 2023-02-09T08:21:51Z

Understood. I wonder if we need to provide multiple copies of the standard libraries (compiled in different modes)?

Another thing: In "uncurried always" mode,
let make: ('a => unit) => ('a => unit) = x => x
compiles fine, but gets reformatted to
let make: ('a => unit, 'a) => unit = x => x
which does not compile.

So far reformatting has been architected to only look at the given file, without knowledge of the project it might be in (if any). So it does not really know the project is in uncurried-always mode. There's a command line, but it would need to be supplied manually at the moment bsc -uncurried always -format Foo.res.
Something to look into later.

cristianoc · 2023-03-09T17:57:23Z

Understood. I wonder if we need to provide multiple copies of the standard libraries (compiled in different modes)?
Another thing: In "uncurried always" mode,
let make: ('a => unit) => ('a => unit) = x => x
compiles fine, but gets reformatted to
let make: ('a => unit, 'a) => unit = x => x
which does not compile.
So far reformatting has been architected to only look at the given file, without knowledge of the project it might be in (if any). So it does not really know the project is in uncurried-always mode. There's a command line, but it would need to be supplied manually at the moment bsc -uncurried always -format Foo.res. Something to look into later.

There's now best-effort support for formatting.

Add support for uncurried-always: a mode where everything is considered uncurried, whether with or without the `.`. This can be turned on with `@@uncurriedAlways` locally in a file. Added a project config `"uncurried"`, which propagates to dependencies, and takes the values: `"legacy"` which changes nothing, or `"default"` for uncurried by default, or `"always"` for uncurried-always.

Using the uncurried-always mode is difficult when calling compiler libraries, as those are uncurried. This introduces automatic curried application in uncurried-only mode: when a curried function is used in application, the application is treated as curried application. This means that even in uncurried-always mode, one can use compiler libraries in most cases. Exceptions are functions that take callbacks, such as `Array.map`.

When functions such as `Array.map` are called via automatic curried application, if one of the arguments is a callback, turn that into an uncurried type. This allows passing an uncurried callback even though the original `Array.map` expects a curried callback.

Instead of using an ad-hoc treatment of function arguments which are callbacks in automatic curried application, use subtyping in uncurried-always mode. So an uncurried function is cast to a curried one during unification. In addition to the existing examples, this also supports uses of `|>` and callbacks to `div` such as `onClick`, which now can be uncurried functions.

…ally in a file. So it behaves just as it does when set via bsconfig.

…always mode.

Project config is not used in the formatter normally. This attempts a best-effort way to find bsconfig.json and see if the mode is set. The editor currently calls this on a temp file, so it tries to find bsconfig from the path of `bsc.exe` used, by looking outside node_modules. A more robust method should be provided later on, but this should be OK to start experimenting.

cristianoc changed the base branch from master to makefile February 1, 2023 10:11

cristianoc force-pushed the uncurried_always branch from 4a53a38 to 4ee15a8 Compare February 1, 2023 10:12

Base automatically changed from makefile to master February 1, 2023 10:12

cristianoc force-pushed the uncurried_always branch from 4ee15a8 to 07e7372 Compare February 1, 2023 10:14

cristianoc requested a review from zth February 1, 2023 10:15

zth approved these changes Feb 1, 2023

View reviewed changes

cristianoc force-pushed the uncurried_always branch 4 times, most recently from 5c1f006 to 6dbc4d1 Compare February 4, 2023 10:19

cristianoc force-pushed the uncurried_always branch from 7b7bfee to 22fa738 Compare February 9, 2023 08:26

cristianoc force-pushed the uncurried_always branch from 22fa738 to c40fb20 Compare March 9, 2023 07:18

cristianoc mentioned this pull request Mar 16, 2023

Status of runtime representation #6077

Closed

cristianoc added 9 commits March 16, 2023 10:54

Update build test.

679dff9

Turn on auto uncurried application when @@uncurriedAlways is used loc…

7253aba

…ally in a file. So it behaves just as it does when set via bsconfig.

Introduce @res.partial to express partial application in uncurried-…

dea80e1

…always mode.

Update CHANGELOG.md

ae484e0

Exception analysis.

4e49037

cristianoc force-pushed the uncurried_always branch from f02d545 to 4e49037 Compare March 16, 2023 09:58

cristianoc merged commit 4304916 into master Mar 16, 2023

cristianoc deleted the uncurried_always branch March 16, 2023 10:44

cristianoc mentioned this pull request Mar 16, 2023

Introduce PervasivesU, uncurried pervasives, in uncurried-always mode. #6079

Merged

fhammerschmidt mentioned this pull request Oct 2, 2023

Document v11 features. rescript-lang/rescript-lang.org#697

Closed

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uncurried always #5968

Uncurried always #5968

cristianoc commented Feb 1, 2023 •

edited

Loading

cristianoc commented Feb 4, 2023

mununki commented Feb 4, 2023 •

edited

Loading

cknitt commented Feb 5, 2023

cristianoc commented Feb 5, 2023

cristianoc commented Feb 5, 2023

cknitt commented Feb 6, 2023 •

edited

Loading

cristianoc commented Feb 9, 2023

cristianoc commented Mar 9, 2023

Uncurried always #5968

Uncurried always #5968

Conversation

cristianoc commented Feb 1, 2023 • edited Loading

cristianoc commented Feb 4, 2023

mununki commented Feb 4, 2023 • edited Loading

cknitt commented Feb 5, 2023

cristianoc commented Feb 5, 2023

cristianoc commented Feb 5, 2023

cknitt commented Feb 6, 2023 • edited Loading

cristianoc commented Feb 9, 2023

cristianoc commented Mar 9, 2023

cristianoc commented Feb 1, 2023 •

edited

Loading

mununki commented Feb 4, 2023 •

edited

Loading

cknitt commented Feb 6, 2023 •

edited

Loading