<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 20, 2015 at 11:49 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"><div id=":1g2" class="a3s" style="overflow:hidden">That's a pity.  For me it is just about two different kinds of wrappers.<br>
Obviously I am not a type expert.</div></blockquote></div><br></div><div class="gmail_extra">The reason it is somewhat uncommon to want a list in a programming language with type systems is that you can't get it to compile if the type check fails. So in such a language, you would have been forced into the product type with a tuple {uint8(), [ty()]} as the only way to represent this. The wrong program would never have existed. Hence it would not be a problem.<br><br></div><div class="gmail_extra">Digging further, you eventually hit granite in the sense that you do need a heterogenous list type. When that happens you are either out of luck, or the type system is expressive enough to let you model it.<br><br></div><div class="gmail_extra">It is, generally, hard to graft a type system unto old code. You may have to fall back to say that your data is [any()]. It is unsatisfactory, but at least it is correct. I think that if you ask the 'typer' program, you get the most specific type in the type lattice which dialyzer can figure out from looking at the code base. If you use this type, you are at least not incorrect, and you are at the limit of what the dialyzer understands, currently.<br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>