<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 19, 2016 at 5:34 PM, Emil Holmstrom <span dir="ltr"><<a href="mailto:emil@update.uu.se" target="_blank">emil@update.uu.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I fail to see the significance of the type system in this case, it doesn't stop Erlang to have a char() type?</blockquote></div><br>Right. You would have to invent a new tag for it, and you would have to potentially take a performance hit due to the new tagging scheme, but adding distinct values at runtime is fairly easy to do. With different tags, $a and 97 are now different values, and conversion between them is now explicit. What makes this idea more powerful in statically typed languages has to do with erasure: once we have a compiled program with a picked representation, we can choose the same representation for multiple types. This is what makes it efficient: char and int are both implemented as integers internally, but the type system protects against misusing one as the other. Erlang terms must be self-describing.</div><div class="gmail_extra"><br></div><div class="gmail_extra">With a more complex type zoo comes the additional burden of managing differences among types however. This is not free for the programmer, and most programming languages try to strike a balance between precision and convenience. Of course, there are different opinions as to what level is needed.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>