<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 20, 2015 at 9:21 AM, Raimo Niskanen <span dir="ltr"><<a href="mailto:raimo+erlang-questions@erix.ericsson.se" target="_blank">raimo+erlang-questions@erix.ericsson.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ideas, anyone?</blockquote></div><br></div><div class="gmail_extra">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:<br><br></div><div class="gmail_extra">-type tagged_list(A) :: {A, [A]}.<br><br></div><div class="gmail_extra">This also opens up the possibility of sum-typing the tagged list:<br><br></div><div class="gmail_extra">-type tagged_list() ::<br></div><div class="gmail_extra">    {tag_a, [..]} | {tag_b, [..]}.<br><br></div><div class="gmail_extra">which in turn can hammer down the precision at which the dialyzer can work.<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>