[erlang-questions] Maps branch and disclaimers

[Björn-Egil Dahlberg]

On 2013-10-30 15:38, Chris King wrote:
> On Wed, 30 Oct 2013 10:24:20 -0400, Björn-Egil Dahlberg 
> <egil@REDACTED> wrote:
>
>
>>     BTW, is there a plan for a type notation for these new maps, or
>>     for how to get Dialyzer to usefully type-check them?
>
>       Yes. The type notation is the same as with other terms.
>
>
> Ya, I just found that and posted a separate e-mail with my analysis. 
>  I believe the type signatures to be inconsistently specified.
>
>
>     How well Dialyzer would be able to handle it is a different
>     matter. I plan to make them really stupid at first, meaning opaque
>     map(). Later incarnations of dialyzer could be increasingly smarter.
>
>
> I think it will be very difficult for Dialyzer to automatically tease 
> apart the homogeneous (list-like) and heterogeneous (tuple-like) use 
> cases, even if they are not mixed.  In particular, as I mentioned in 
> my other e-mail, the useful type variance in the heterogeneous use 
> case is the opposite of the useful type variance in the homogeneous 
> case.  (i.e., we want to know that a heterogeneous map contains *at 
> least* some keys; we want to know that a homogeneous map contains *at 
> most* some keys).
>
> Maybe I am wrong – I hope I am – but without a plan and without the 
> hetero-homogeneous distinction, I fear "later" could be "never".

First, I'm far from a Dialyzer expert ..

However, I think we can view maps as functions and the pairs as function 
clauses. It should be the same problem space, i.e. range and domains, 
product and unions.

so,

-spec wat() -> #{ binary() => integer()}.

would exhibit the same problem/solution as,

-spec foo(binary()) -> integer().

foo(B) when is_binary(B) -> binary_to_integer(B).

That's my view at least, I could very well be wrong also here.
But as I said, for a first stab at it, it should be strictly opaque map().

I've looked at your other mail but I don't have time to get into the 
details right now.
Thank you for feedback! It is much appreciated and I will look into it 
when the time arrives!

// Björn-Egil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131030/6e7adbee/attachment.htm>