-
Notifications
You must be signed in to change notification settings - Fork 35
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
Support for rigid type variables #560
Changes from all commits
ac0ed52
4680cf8
1215798
bb0f937
960dc25
e659c85
f7403b3
a103f65
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -30,11 +30,15 @@ | |
af_binary_op/1, | ||
af_constrained_function_type/0, | ||
af_constraint/0, | ||
af_clause/0, | ||
af_guard_seq/0, | ||
af_guard/0, | ||
af_field_name/0, | ||
af_fun_type/0, | ||
af_function_type_list/0, | ||
af_record_field/1, | ||
af_record_field_type/0, | ||
gr_any_type/0, | ||
af_singleton_integer_type/0, | ||
af_string/0, | ||
af_unary_op/1, | ||
|
@@ -244,6 +248,7 @@ | |
| af_tuple_type() | ||
| af_type_union() | ||
| af_type_variable() | ||
| gr_rigid_type_variable() | ||
| af_user_defined_type(). | ||
|
||
-type af_annotated_type() :: | ||
|
@@ -308,6 +313,14 @@ | |
-type gr_type_var() :: atom() | string(). | ||
-type af_type_variable() :: {'var', anno(), gr_type_var()}. | ||
|
||
%% Gradualizer: `rigid_var' is used for type variables (instead of plain `var') | ||
%% originating from specs of the currently checked function. They are rigid | ||
%% in the sense that they are fixed but completely unknown from the perspective | ||
%% of the function definition. We want to be able to differentiate between | ||
%% flexible (`var') and rigid type variables, and therefore we add this new | ||
%% syntactic form although they are syntactically the same. | ||
-type gr_rigid_type_variable() :: {'rigid_var', anno(), atom()}. | ||
|
||
-type af_user_defined_type() :: | ||
{'user_type', anno(), type_name(), [abstract_type()]}. | ||
|
||
|
@@ -338,6 +351,8 @@ | |
[af_lit_atom('is_subtype') | | ||
[af_type_variable() | abstract_type()]]}. % [IsSubtype, [V, T]] | ||
|
||
-type gr_any_type() :: {'type', anno(), 'any', []}. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do we need to add this? I think it's covered by this definition: -type af_predefined_type() ::
{'type', anno(), type_name(), [abstract_type()]}. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not necessarily needed. I used it here to emphasise that -record(env, {fenv = #{} :: #{{atom(), arity()} =>
[gradualizer_type:af_constrained_function_type()]
| [{'type', gradualizer_type:anno(), 'any', []}]
}, but I'm not sure whether it's better. What would you do? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK. I'm fine with any. :-) |
||
|
||
-type af_singleton_integer_type() :: af_integer() | ||
| af_character() | ||
| af_unary_op(af_singleton_integer_type()) | ||
|
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,21 @@ | ||
-module(opaque_fail). | ||
|
||
-export([use_external/2]). | ||
-export([use_external/2, update_without_opaque/0, add_to_opaque/0, return_opaque/0]). | ||
|
||
-spec use_external(user_types:my_opaque(), integer() | undefined) -> integer(). | ||
use_external(I, undefined) -> I; | ||
use_external(_, I) -> I. | ||
|
||
-spec update_without_opaque() -> ok. | ||
update_without_opaque() -> | ||
_Val = user_types:update_opaque(3), | ||
ok. | ||
|
||
-spec add_to_opaque() -> ok. | ||
add_to_opaque() -> | ||
Val = user_types:new_opaque(), | ||
Val + 1, | ||
ok. | ||
|
||
-spec return_opaque() -> user_types:my_opaque(). | ||
return_opaque() -> 3. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since most of this file is copied from OTP, we want to explain all our changes with comments. The prefix "gr" is good but maybe something more about why we want to add this type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I added the missing comment, together with a forgotten doc for the
make_rigid_type_vars/1
(with a slightly different wording): 5a18b8e. Is it better now?