[erlang-questions] Tricky Dialyzer type

[Raimo Niskanen]

On Mon, Jul 20, 2015 at 08:49:10PM +0200, Erik Søe Sørensen wrote:
> Depending on exactly what tagged tuples have already been assigned meaning,
> there may be other options.
> If only 2-tuples are "occupied", you can use {magic, Tag, List}.
> If only tuples with an initial atom are "occupied", you can use {{Tag},
> List}.
> Are all tuple types indeed spoken for?
> On the other hand, it sounds like all list types are available. In that
> case, a term like [{Tag, List}] might work better - it has different
> trade-offs, at least, with respect to type analysis.

Creative ideas, but [{Tag,List}] is already spoken for, and I thought
{magic, Tag, List} was ugly as well as {{Tag}, List}.

{Tag,undefined} is not spoken for and that is my best plan B.
But now I have:
    [{Tag,Val}, {Tag,OtherVal}, ...] for a sequence with size >= 1 note
        that all Tags have to be equal or else there is an error
    [] for No Value i.e nonexistent
    {Tag,undefined} for a sequence with size 0
Ugly and inconsistent.

With the tagged list:
    [Tag|[Val,...]] for a sequence with size >= 1
    [Tag] for a sequence with size == 0
    [] for No Value i.e nonexistent.
which I think is much more consistent.

/ Raimo


> 
> /Erik
> Den 20/07/2015 11.49 skrev "Raimo Niskanen" <
> raimo+erlang-questions@REDACTED>:
> 
> > On Mon, Jul 20, 2015 at 10:06:32AM +0200, Jesper Louis Andersen wrote:
> > > On Mon, Jul 20, 2015 at 9:21 AM, Raimo Niskanen <
> > > raimo+erlang-questions@REDACTED> wrote:
> > >
> > > > Ideas, anyone?
> > >
> > >
> > > Your representation is icky at the type level. If possible, go for a
> > tuple
> > > instead since it has type A*B as a product and then this is fairly easy
> > to
> > > represent:
> >
> > Unfortunately that is not possible since the tagged tuple already has
> > another meaning in the code I am trying to add this feature to.  This was
> > the "exhausted option" I briefly mentioned.  I should have stated that
> > explicitly in my question...
> >
> > >
> > > -type tagged_list(A) :: {A, [A]}.
> > >
> > > This also opens up the possibility of sum-typing the tagged list:
> > >
> > > -type tagged_list() ::
> > >     {tag_a, [..]} | {tag_b, [..]}.
> > >
> > > which in turn can hammer down the precision at which the dialyzer can
> > work.
> > >
> > > In naive type systems, list are homogeneous in the sense that every
> > element
> > > has to be drawn from the same ground type. Properly handling lists where
> > > the "first element drives the type of the remainder of the list" is
> > nudging
> > > itself towards the land of dependent type theory, which the dialyzer
> > > definitely doesn't support.
> >
> > That's a pity.  For me it is just about two different kinds of wrappers.
> > Obviously I am not a type expert.
> >
> > >
> > > It may be possible to work with the notion of "list of two elements",
> > > [uint8(), ty(), ...], saying that the list is a cons of uint8() followed
> > by
> > > one or more elements of type ty(), but I'm not sure if the dialyzer
> > > understands this at all.
> >
> > At least list(type(), type()) and [type(), type()] both gives syntax errors
> > so it seams that Dialyzer does not understand that at all.
> >
> > >
> > >
> > >
> > > --
> > > J.
> >
> > > _______________________________________________
> > > erlang-questions mailing list
> > > erlang-questions@REDACTED
> > > http://erlang.org/mailman/listinfo/erlang-questions
> >
> >
> > --
> >
> > / Raimo Niskanen, Erlang/OTP, Ericsson AB
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >

> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions


-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB