Comments (3)
Yeah! So, what's the way forward?
Ideally, we convince the OTP team to include the intersection type in the official type language. My colleage Karol says that he has reported this years back but it has not been prioritized.
Until then, we can add it in our type, which we could export in the main interface module, i.e. gradualizer:type()
. Then we just need to implement pretty-printing for it as a special case and handle it in the typechecker. I don't see that we need to do anything else. Do you?
Then, how should it be represented?
I suggest {type, erl_anno:anno(), intersection, [type()]}
.
For the syntax (pretty-printing, documentation, etc.), I suggest the semicolon T1 ; T2
. Can it only be used for fun types or do we for example ever need to intersect with any()
? If it's only for fun types, I think the first of these syntaxes would be nice; otherwise the second:
-type t() :: fun((boolean()) -> its_a_bool;
(integer()) -> its_an_int).
-type t() :: fun((boolean()) -> its_a_bool);
fun((integer()) -> its_an_int).
If we want to allow T1 ; T2
for any types, is there any risk of syntax ambiguity when mixing specs with intersection types?
-spec foo(boolean() | atom()) -> fun((boolean() -> its_a_bool) ;
fun((atom()) -> its_an_atom) ;
(integer()) -> its_an_int.
from gradualizer.
I think intersection with any()
could be temporary solution for handling conditional expressions before refinement types are fully implemented.
for exampe
case get_int() of
PosInt when PosInt > 0 -> handle_pos_int(PosInt);
_ -> ...
end.
-spec get_int() -> integer().
-spec handle_pos_int(pos_integer()) -> any().
We could infer the type of PosInt
to be integer() ; any()
(ie. some subset of integer()
)
(I think that intersection is most useful during internal type checking and apart from funs we don't necessarily have to allow it for arbitrary types as user definitions (ie no need to include in OTP). However pretty-printing intersection of any two types can be useful if Gradualizer type calculation arrives to such a type)
from gradualizer.
I don't have broad knowledge of history and syntax in other languages.
Could you explain me why ;
is a good fit for intersection or why it is used in specs already? To me ;
feels like OR
, while intersection feels like AND
(aka ,
).
(I understand that in specs ;
is used, maybe there it also stems from a kind of OR
notion, as in "function arg can be integer() OR atom()" rather than "function must handle integer() AND atom() arg")
If it is the opposite in some sense of union it could be &
. (that could avoid bit of ambiguity too)
Another question: would it be allowed in fun types for the domains to not be disjoint? (eg. fun( (2) -> atom(); (integer()) -> list() )
)
from gradualizer.
Related Issues (20)
- Crash with Uncaught error: function_clause HOT 6
- Crash with `Uncaught error: {case_clause, ..` in `typechecker:do_type_check_expr/2`
- Crash with Uncaught error: {badkey, ...} HOT 1
- No clause for gradualizer_lib:pick_value(module()) HOT 2
- No clause of gradualizer_lib:pick_value(any()) HOT 2
- Support the new dynamic() type
- `ok bsr ok` crashes erl_eval:do_apply/7 HOT 4
- An invalid utf32 value can crash eval_bits:eval_exp_field/6
- Crash in gradualizer_fmt:format_type_error: no function_clause_matching
- Crash in typechecker:do_type_check_expr_in/3: bad_key in map_get/2
- Invalid polymorphic code accepted HOT 2
- Support old-style 'catch' keyword HOT 5
- Wrong type in receive...after Timeout
- `binary_to_atom/1` breaks compatibility below OTP 23 HOT 4
- Solving local constraints at each function call to a polymorphic function HOT 6
- support for OTP 26 map comprehensions
- Wrong type location reported?
- Gradualizer can't tell that `m` and `f` don't exist in `erlang:apply(m, f, [some, args])` HOT 2
- Exhaustivity checking issue
- Type representation HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gradualizer.