Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require type annotations for builtins #941

Open
jjcnn opened this issue Feb 5, 2021 · 0 comments
Open

Require type annotations for builtins #941

jjcnn opened this issue Feb 5, 2021 · 0 comments
Labels
backwards-incompatible-change good first issue Good for newcomers inconsistency Inconsistency with other parts of the code libraries / builtins
Milestone

Comments

@jjcnn
Copy link
Contributor

jjcnn commented Feb 5, 2021

We currently use the argument types for builtins to determine which version of the builtin we want to invoke:

let x = Uint128 0
let y = Uint128 1
let z = builtin add x y   (* add : forall 'A. 'A -> 'A -> 'A. 'A is inferred to be Uint128 in this case. *) 

This is inconsistent with the rest of Scilla, where we require explicit type arguments for polymorphic types:

let x = Uint128 0
let y = Uint128 1
let my_add = tfun 'A => fun (x : 'A) => fun (y : 'A) => x
let z = let f = @my_add Uint128 in f x y

Now that we have added type arguments to builtins, it makes more sense to require type arguments for polymorphic builtins:

let x = Uint128 0
let y = Uint128 1
let z1 = builtin add {Uint128} x y    (* Legal *)
let z2 = builtin add {Uint32} x y     (* Illegal : value arguments do not correspond to the type argument *)
let z3 = builtin add x y             (* No longer legal : type argument required *)

See also #598.

@jjcnn jjcnn added good first issue Good for newcomers inconsistency Inconsistency with other parts of the code libraries / builtins backwards-incompatible-change labels Feb 5, 2021
@jjcnn jjcnn added this to the Scilla 1.0.0 milestone Feb 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backwards-incompatible-change good first issue Good for newcomers inconsistency Inconsistency with other parts of the code libraries / builtins
Projects
None yet
Development

No branches or pull requests

1 participant