<p dir="ltr">Depending on exactly what tagged tuples have already been assigned meaning, there may be other options.<br>
If only 2-tuples are "occupied", you can use {magic, Tag, List}.<br>
If only tuples with an initial atom are "occupied", you can use {{Tag}, List}.<br>
Are all tuple types indeed spoken for?<br>
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.</p>
<p dir="ltr">/Erik</p>
<div class="gmail_quote">Den 20/07/2015 11.49 skrev "Raimo Niskanen" <<a href="mailto:raimo%2Berlang-questions@erix.ericsson.se">raimo+erlang-questions@erix.ericsson.se</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jul 20, 2015 at 10:06:32AM +0200, Jesper Louis Andersen wrote:<br>
> On Mon, Jul 20, 2015 at 9:21 AM, Raimo Niskanen <<br>
> <a href="mailto:raimo%2Berlang-questions@erix.ericsson.se">raimo+erlang-questions@erix.ericsson.se</a>> wrote:<br>
><br>
> > Ideas, anyone?<br>
><br>
><br>
> Your representation is icky at the type level. If possible, go for a tuple<br>
> instead since it has type A*B as a product and then this is fairly easy to<br>
> represent:<br>
<br>
Unfortunately that is not possible since the tagged tuple already has<br>
another meaning in the code I am trying to add this feature to.  This was<br>
the "exhausted option" I briefly mentioned.  I should have stated that<br>
explicitly in my question...<br>
<br>
><br>
> -type tagged_list(A) :: {A, [A]}.<br>
><br>
> This also opens up the possibility of sum-typing the tagged list:<br>
><br>
> -type tagged_list() ::<br>
>     {tag_a, [..]} | {tag_b, [..]}.<br>
><br>
> which in turn can hammer down the precision at which the dialyzer can work.<br>
><br>
> In naive type systems, list are homogeneous in the sense that every element<br>
> has to be drawn from the same ground type. Properly handling lists where<br>
> the "first element drives the type of the remainder of the list" is nudging<br>
> itself towards the land of dependent type theory, which the dialyzer<br>
> definitely doesn't support.<br>
<br>
That's a pity.  For me it is just about two different kinds of wrappers.<br>
Obviously I am not a type expert.<br>
<br>
><br>
> It may be possible to work with the notion of "list of two elements",<br>
> [uint8(), ty(), ...], saying that the list is a cons of uint8() followed by<br>
> one or more elements of type ty(), but I'm not sure if the dialyzer<br>
> understands this at all.<br>
<br>
At least list(type(), type()) and [type(), type()] both gives syntax errors<br>
so it seams that Dialyzer does not understand that at all.<br>
<br>
><br>
><br>
><br>
> --<br>
> J.<br>
<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
<br>
--<br>
<br>
/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>