Utility macros for types about gradualizer HOT 7 CLOSED

@Zalastax no-no, I just meant these macros for internal use

from gradualizer.

I like it very much!

@josefs wrote

We'd have to be very careful about normalizing the types in order for pattern matching to work correctly with the annotations

I think it shouldn't matter. The macros should use _ for matching the annotation.

Analogous to the type/1,2 functions (for expressions), I suggest these ?type/1,2 macros for patterns:

-define(type(T), {type, _, T, []}).
-define(type(T, Args), {type, _, T, Args}).

I don't think we need macros for expressions, since we have the functions for that. Possibly we could name the macros type_pat to make it clear that it's a pattern.

from gradualizer.

I like the idea of simplifying pattern matching using macros. We'd have to be very careful about normalizing the types in order for pattern matching to work correctly with the annotations, but that's a good thing.

I interested to hear what other people think about this.

from gradualizer.

A possibility is to have separate macros for patterns and expressions. Something like

-define(t_any, {type, erl_anno:new(0), any, []}).
-define(t_any_p, {type, _, any, []}).

Another, perhaps nicer, option is to have a variant which takes the annotation as an argument that you can use in patterns:

-define(t_any(Ann), {type, Ann, any, []}).
-define(t_any(), ?t_any(erl_anno:new(0))).

from gradualizer.

The good thing about record syntax is that #type{name = any, params = []} matches any value in the anno field (so we don't have to care whether the type was normalised and position removed or not). When constructing the record the not mentioned field (anno) gets the default value, again win-win :)
I think it is an advantage that we don't have to have separate macros for matching and construction (so I wouldn't spoil it). Ann as extra macro arg otoh can be ambiguous (eg ?t_list(Ann) vs ?t_list([?t_integer])) - but if we only allow extra Ann arg with the variant with the most args then its fine (eg ?t_list, ?t_list([?_integer]), ?t_list([?t_integer], ?t_nil), ?t_list(Ann, [?t_integer], ?t_nil)

In the rare case when we want to copy the annotation from one type to the other, we could use the tuple or record representation directly (bit inconsistent look) or have a pair of getter/setter functions (or the extra Ann arg to the macro, that Ulf proposed).

from gradualizer.

Does this relate to #85?

from gradualizer.

Now, the macros for patterns are added in master and we have the type/1,2 functions for expressions. Perhaps we can close this?

At first I didn't get Péter's macro trick, but it's pretty clever: using a record to allow the same macro to be used in patterns and in expressions. The annotation is ignored in patterns and gets the annotation erl_anno:new(0) in expressions. It is pretty clever, but it wouldn't pass the Gradualizer, unless we fix #121.

from gradualizer.