New mechanism to determine arity of externals. #6874
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cristianoc
force-pushed
the
new_external_arity
branch
from
610d619 to
908ffe8
Compare
cristianoc
force-pushed
the
new_external_arity
branch
from
908ffe8 to
98ff408
Compare
cristianoc
force-pushed
the
new_external_arity
branch
from
98ff408 to
7a53982
Compare
The arity of external declarations is currently determined just based on the untyped parse tree. This is probably because the "real" arity is ambiguous in curried mode, and the convention is that an explicit type of the form `t1 => t2 => t3` determines arity 2, but type aliases are ignored. Here's an example: https://rescript-lang.org/try?version=v11.1.2&code=C4TwDgpgBArlC8UAUBLAdsANFdwCUCAfDhgFAACAbgIYA2UEAHsBAE5p1SUCMAXLAigAiSkKgB6cVGqsUoKADNWAewC2AlAGccqsLRQBjORRr0mLdp0oAmfqgzZcBeMVyCRYydNnytDRnqGxqS0EMCK3IKMRFzcSIyYjHghYYrWUTE28YnJQA In the example ```res type u = (int, int) => int @Val external v1: u = "v" // arity from u is implicit @Val external v2: (int, int) => int = "v" // arity is explicit let f1 = x => v1(x,x) let f2 = x => v2(x,x) ``` we have that `v2` is determined to have arity 2, but the arity of `v1` is not determined. As a consequence, the code generated for `f1` uses runtime `Curry`, both in curried an uncurried mode. This PR uses the actual type coming from the type checker when in uncurried mode, as that does not suffer from ambiguity. The consequences are that the external behaves the same however the type is defined, and in the example, no `Curry` runtime is generated.
cristianoc
force-pushed
the
new_external_arity
branch
from
7a53982 to
5dfdabf
Compare
zth
approved these changes
Jul 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The arity of external declarations is currently determined just based on the untyped parse tree. This is probably because the "real" arity is ambiguous in curried mode, and the convention is that an explicit type of the form
t1 => t2 => t3determines arity 2, but type aliases are ignored.Here's an example:
https://rescript-lang.org/try?version=v11.1.2&code=C4TwDgpgBArlC8UAUBLAdsANFdwCUCAfDhgFAACAbgIYA2UEAHsBAE5p1SUCMAXLAigAiSkKgB6cVGqsUoKADNWAewC2AlAGccqsLRQBjORRr0mLdp0oAmfqgzZcBeMVyCRYydNnytDRnqGxqS0EMCK3IKMRFzcSIyYjHghYYrWUTE28YnJQA
In the example
we have that
v2is determined to have arity 2, but the arity ofv1is not determined. As a consequence, the code generated forf1uses runtimeCurry, both in curried an uncurried mode.This PR uses the actual type coming from the type checker when in uncurried mode, as that does not suffer from ambiguity.
The consequences are that the external behaves the same however the type is defined, and in the example, no
Curryruntime is generated.