[erlang-questions] Maps branch and disclaimers

[Chris King]

Comments on the type specifications in the EEP:

> Keys known before hand can be specified directly and uniquely for a map.
> -spec func(Opt, M) -> #{ 'status' => S, 'c' => integer() }

Does this mean the returned map must contain exactly those keys?  At least  
those keys?  At most those keys?  If either of the latter, does this  
meaning reverse when the map is an input to the function?


> spec plist_to_map(Ls) -> #{ binary() => integer() }

Does this means plist_to_map must return a map containing:

a) exactly one key, which is a binary;
b) any number of keys, exactly one of which is a binary;
c) any number of keys, at most one of which is a binary;
d) any number of keys, which are all binaries;
f) any number of keys, which may be any type, but those of which are  
binaries, must map to integers;
g) same as (f), but meaning at *least* one of which is a binary;
h) a map mapping every possible binary to an integer?

I mention (h) only because it clearly is impossible, yet if the  
interpretation in the previous example is "exactly those keys" or "at  
least those keys", then the interpretation here must be (h) or a variant  
thereof.

I corroborate with this example from the EEP:

> -type map2() :: #{ <<"list1">> | <<"list2">> => [numbers()] }.

which implies that the key types are not special-cased for atoms.

Therefore, we can conclude that a map type-specification on the RHS of a  
function must mean "a map containing at most those keys"; which, while  
useful for the "dict" usage, is hardly useful for "record" usage.  Knowing  
only that the returned map does *not* contain most keys is useless when  
I'm trying to ensure that it contains the one key I'm interested in.


The best way to fix this IMO is to separate homogeneous and heterogeneous  
maps.  Homogeneous map types can then have "at most" semantics (to support  
iteration), while heterogeneous map types can have "at least" semantics  
(to support lookup).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131030/88e1b65f/attachment.htm>