Péter Gömöri

just an interesting note: I sometimes use andalso/orelse in the body of match-specs where conditional expressions are not allowed eg: ``` dbg:fun2ms(fun(_) -> message( element(1,caller()) =/= mymod andalso caller() )...

(just for the record, sorry I did not add it earlier) @zuiderkwast run the question through the erlang mailing list, which became a quite lengthy discussion (thread starts here: http://erlang.org/pipermail/erlang-questions/2018-July/096024.html)...

I am afraid as of master @ d74675abc3c739e70e04122354f1cd5a642f1766 we have a bit inconsistent implementation. While type checking accepts any type as second argument (only needs to be subtype of the...

exactness is a good idea: I could imagine having a weakest level with only the topmost types (`atom() | integer() | float() | tuple() | list() | map() | bitstring()...

thanks, Ulf, for starting this thread to clarify this hazy topic. I also only had gut feelings about "maybe" referring to properness, as Viktor described. I like the definitions basing...

I support NoYes. (I base this intuition on the definitions of iolist and iodata - which I think are the most used and very widely used maybe-improper lists - and...

happy new year! I'm very glad to see the new momentum

I accidentally pushed "Ready for review", sorry I just wanted to comment that I agree with @zuiderkwast that there is value in keeping band (and friends) with current implementation and...

the idea came up on ElixirConf EU. Now that I'm checking, it does not seem to be possible to specify types of fields when defining a struct (unlike typed_record_def). The...

Hi @tim2CF - we were thinking about adding gradualizer specific attributes. - in the general case I imagine dialyzer options are not really applicable for gradualizer. however in the special...