[erlang-questions] Maps branch and disclaimers
Thu Oct 31 11:58:18 CET 2013
Write an unary function with 15 (might need more) different clauses f(a1) -> ...; ...; f(a15) -> ....
Dialyzer will infer atom() for the argument type because large type unions are broadened to make the various type unifications happen in a reasonable time, if I understand this correctly.
This kind of validates what I said about types being used to reject sure-to-fail calls.
At least that's how I see success typing as opposed to more traditional type systems.
I may be completely wrong.
> Le 30 oct. 2013 à 17:07, "Chris King" <> a écrit :
>> On Wed, 30 Oct 2013 11:36:12 -0400, Anthony Ramine <> wrote:
>> In the foo/1 spec, the binary() doesn’t mean that foo/1 handles *all* binaries, it means that if you give something that is not a binary(), the call is guaranteed to fail.
> Mm, the Erlang reference manual is unclear about the correct interpretation. Dialyzer's interpretation differs with the -Wunderspecs flag:
> $ cat > foo.erl
> -spec bar(integer()) -> ok.
> bar(42) -> ok.
> $ dialyzer foo.erl
> done (passed successfully)
> $ dialyzer -Wunderspecs foo.erl
> foo.erl:3: Type specification foo:bar(integer()) -> 'ok' is a supertype of the success typing: foo:bar(42) -> 'ok'
> done (warnings were emitted)
> The latter is more useful to me – I would like to know from the spec that a function can handle certain inputs (or, in the case of a heterogeneous map, will produce certain outputs). Knowing that "the function will return this type or crash" is less useful.
> (And the benefit from this interpretation – knowing that given certain inputs, the function will *definitely* crash, is not generally useful (and I have used languages where this is expressible). I realize that internally this is how Dialyzer works, but that does not mean the type language must work his way.)
> Without a firm definition, it's not possible to say how function specs "should" be interpreted.
> FWIW Dialyzer *can* (with -Wunderspecs) check the heterogeneous map type-analogous case of a function returning a function. (i.e. it can check that the returned function accepts at *least* the specified values; just as with a heterogeneous map, we care whether it contains at *least* the specified keys.)
>> PS: Your MUA sends rich text in 12px.
> *checks settings* Ah, it was set to "prefer text/reply with same formatting". Fixed, thanks.
More information about the erlang-questions