Closed cristianoc closed 1 month ago
Here's a test of how easily one can pick up the meaning of this as well as the %ffi
directive with no previous context.
Interactive session with gpt3.5.
What does this ReScript code do?
@@future(uncurriedByDefault, ffiArityCheck)
let sum : (int, int) => int = %ffi(
function(x,y) { return x+y; }
)
This ReScript code defines a function called sum
that takes two integers as arguments and returns an integer. The function is implemented using a foreign function interface (FFI) to call a JavaScript function that performs the addition.
Here's a breakdown of the code:
@@future(uncurriedByDefault, ffiArityCheck)
: This is a compiler directive that sets some options for the future
feature of ReScript. The uncurriedByDefault
option indicates that uncurried functions should be used by default, and ffiArityCheck
enables arity checking for FFI functions.
let sum : (int, int) => int = %ffi(
function(x,y) { return x+y; })
: This line declares a variable named sum
and assigns it a function type (int, int) => int
. The =>
symbol represents a function type in ReScript. The implementation of the sum
function is specified using the %ffi
syntax, which allows embedding JavaScript code within ReScript. In this case, the JavaScript code is function(x,y) { return x+y; }
, which adds the x
and y
parameters and returns the result.
In summary, this code defines a ReScript function sum
that uses an FFI to call a JavaScript function responsible for adding two numbers.
Explain the future directive to me.
The @@future
directive in ReScript is used to enable and configure the usage of experimental language features. It allows you to opt into features that are still under development or may not be fully supported or stable yet.
The @@future
directive takes one or more arguments that specify the options for the enabled features. These options are comma-separated and enclosed in parentheses.
Here are a couple of options commonly used with @@future
:
uncurriedByDefault
: This option specifies that uncurried functions should be used by default. Uncurried functions in ReScript are functions that take multiple arguments as a tuple, rather than currying them. Currying is the process of transforming a function that takes multiple arguments into a sequence of functions, each taking a single argument. By enabling this option, you can define functions that take multiple arguments without explicitly currying them.
ffiArityCheck
: This option enables arity checking for foreign function interface (FFI) functions. When using the %ffi
syntax to embed JavaScript or other foreign code within ReScript, arity checking verifies that the number of arguments passed to the FFI function matches the expected arity. This helps catch potential errors when calling FFI functions.
It's important to note that features enabled using @@future
are experimental and subject to change. They may not be fully supported or behave as expected. Therefore, it's recommended to use them with caution and be aware of the potential risks and limitations.
The @@future
directive allows developers to experiment with upcoming language features and provide feedback to the ReScript development team, contributing to the evolution of the language.
Should this be accompanied by an option in the config as well? So things can be turned on project wide.
Should this be accompanied by an option in the config as well? So things can be turned on project wide.
Yes
probably something for the upcoming rescript.json
file @cometkim
probably something for the upcoming
rescript.json
file @cometkim
Actually we could merge the rescript.json
PR pretty soon if we could gate it, no need to wait for v11. Goes both ways.
The other natural one is this https://github.com/rescript-lang/rescript-compiler/pull/6102 as it's ready to do but we don't want to cause too many output changes for people who try out v11.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Sometimes features in the compiler are ready ahead of time, but for some reason they belong to the next version of the compiler. Instead of letting them leave in some branch, that needs rebasing and maintenance, they can be gated under an
@@future
directive. The idea is thatwill enable all the future features.
And one can select individual one using
@@future(feat1, feat2)