<br><br><div class="gmail_quote">On Wed, Dec 9, 2009 at 7:47 PM, wren ng thornton <span dir="ltr">&lt;<a href="mailto:wren@freegeek.org">wren@freegeek.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Andrew Coppin wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What we&#39;re really trying to do here is attach additional information to a value - information which exists only in the type checker&#39;s head, but has no effect on runtime behaviour (other than determining whether we *get* to runtime). As far as I can tell, Haskell does not provide any way to take an existing type and attach additional information to it in such a way that code which cares about the new information can make use of it, but existing code which doesn&#39;t care continues to work. Any comments on this one?<br>

</blockquote>
<br></div>
In defense of Haskell, that&#39;s not what the semantics of newtype are. The semantics of newtype declare that the, er, new type is unrelated to the old type--- despite however they may be represented at runtime. Thus, allowing functions to ignore the newtype wrapper would defeat the intentions of using newtypes in the first place. I actually find this to be one of the most powerful things in the type system of H98, and I miss having them in every other language where I&#39;m forced to sacrifice performance or correctness.<br>

<br></blockquote><div><br>What caught me about Andrew&#39;s idea is that it would allow for kind polymorphism in a useful way.  Or at least, in a way that I tend to yearn for it.<br><br>Do you have anyway to get kind polymorphism?<br>
<br>Jason<br></div></div>