<!DOCTYPE html><html><head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<style type="text/css">body { font-family:'DejaVu Sans Mono'; font-size:12px}</style>
</head>
<body bgcolor="#FFFFFF" text="#000000"><div>Comments on the type specifications in the EEP:</div><div><br></div><div>> Keys known before hand can be specified directly and uniquely for a map.</div><div>> -spec func(Opt, M) -> #{ 'status' => S, 'c' => integer() }</div><div><br></div><div>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?</div><div><br></div><div><br></div><div>> spec plist_to_map(Ls) -> #{ binary() => integer() }</div><div><br></div><div>Does this means plist_to_map must return a map containing:</div><div><br></div><div>a) exactly one key, which is a binary;</div><div>b) any number of keys, exactly one of which is a binary;</div><div>c) any number of keys, at most one of which is a binary;</div><div>d) any number of keys, which are all binaries;</div><div>f) any number of keys, which may be any type, but those of which are binaries, must map to integers;</div><div>g) same as (f), but meaning at *least* one of which is a binary;</div><div>h) a map mapping every possible binary to an integer?</div><div><br></div><div>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.</div><div><br></div><div>I corroborate with this example from the EEP:</div><div><br></div><div><div>> -type map2() :: #{ <<"list1">> | <<"list2">> => [numbers()] }.</div><div><br></div><div>which implies that the key types are not special-cased for atoms.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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).</div></div></body></html>