
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">I meant to retain the separate types Int and Int#, but to assign both of them the same kind *. </div><div class=""><br class=""></div><div class="">I believe the unboxed kind # was added to prevent polymorphic functions being instantiated at unboxed types. This is done because while values with types of kind * have a uniform representation, values with types of kind # do not, so the usual code generation approach does not work.</div><div class=""><br class=""></div><div class="">The solution I was proposing was to allow polymorphic functions to be used at unboxed types, and do the code generation by simply specialising those functions for the types they are instantiated at. You would need to compile each polymorphic function several times, but then if someone is writing code that uses explicit unboxed types the associated functions are probably INLINEd anyway. The Int type would still be lazy/lifted, and Int# unlifted, so that would not have to change.</div><div class=""><br class=""></div><div class="">If you think the above plan would not work then I’d like to hear about it. I was planning to do something like it for DDC (which still progresses..)</div><div class=""><br class=""></div><div class="">Ben.</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 9 Feb 2016, at 4:39 am, Edward Kmett <<a href="mailto:ekmett@gmail.com" class="">ekmett@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">This doesn't really work in a non-strict language like Haskell with uncontrolled recursion. We often need a lazy int that may be _|_ and shouldn't affect termination of the program unless demanded.<div class=""><br class=""></div><div class="">The result would be that you'd actually have to compile all of your code several ways times the number of type arguments and you'd get rather severely different semantics around evaluation as it switched between strictness and laziness. </div><div class=""><br class=""></div><div class="">Moreover, cycles that happened to involve one of these values would have to tie the knot strictly, meaning you'd have issues like scheme where letrec secretly exposes extra, observable, #f cases when you encounter a cycle.</div><div class=""><br class=""></div><div class="">-Edward</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Feb 7, 2016 at 7:17 AM, Ben Lippmeier <span dir="ltr" class=""><<a href="mailto:benl@ouroborus.net" target="_blank" class="">benl@ouroborus.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">

> On 7 Feb 2016, at 9:50 pm, Joachim Durchholz <<a href="mailto:jo@durchholz.org" class="">jo@durchholz.org</a>> wrote:<br class="">

<br class="">

> For the Int/Int# concept, the approaches I have seen either ignore the efficiency and let the machine figure out what to do (Smalltalk, Python, pre-Int# Haskell), or they complicate the type system at the expense of polymorphism (Java, Eiffel), or they complicate the type system even more to regain some form of polymorphism (C++, today's Haskell).<br class="">

<br class="">

</span>Although I haven’t implemented it, I suspect another approach is to just specialise every polymorphic function at its unboxed type arguments. Boxed and unboxed value types would share the same kind. Of course, full specialisation of polymorphic code assumes that code is available in the interface files, but we’ve almost got that already. Dealing with mutual recursion could be a pain, though.<br class="">

<br class="">

I don’t think specialisation was an option back when unboxed types were originally implemented. I believe GHC’s support for cross module inlining came some time after the unboxed types, if the publication dates of the relative papers are to be a guide.<br class="">

<span class="HOEnZb"><font color="#888888" class=""><br class="">

Ben.<br class="">

</font></span><div class="HOEnZb"><div class="h5"><br class="">

_______________________________________________<br class="">

Haskell-Cafe mailing list<br class="">

<a href="mailto:Haskell-Cafe@haskell.org" class="">Haskell-Cafe@haskell.org</a><br class="">

<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">

</div></div></blockquote></div><br class=""></div>

</div></blockquote></div><br class=""></body></html>