On Sat, Mar 3, 2012 at 8:06 AM, Twan van Laarhoven <span dir="ltr"><<a href="mailto:twanvl@gmail.com">twanvl@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">I expect that this will not be easy to implement, because it requires interaction with things like the garbage collector. For example, UnboxPair will need a different info table for different a and b.</div>
<br>
It might be possible to essentially specialize UnboxPair for each different a and b for which it is used, but that gets tricky with generic code.<br></blockquote><div><br></div><div>I believe use-site code generation is the way to go. This is what C++ does (at compile time) and C# (at runtime, using the JIT) does.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
The Unbox type class would be similar in spirit to the class with the<br>
same name in the vector package, but be implemented internally by GHC.<br>
To a first approximation instances would only exist for fields that<br>
unpack to non-pointer types (e.g. Int.)<br>
<br>
Second idea: Introduce a new pragma, that has similar effect on<br>
representations as DPH's [::] vector type. This new pragma does deep<br></div>
unpacking, allowing for more types to be instances of the Unbox type.<br>
</blockquote>
<br>
Could this be handled by just having/deriving an Unbox instance for (a,b)? I imagine the Unbox type class would have to contain essentially the same things as Storable, maybe something like<br>
<br>
type UnboxedRepr :: Int -> #<br>
class Unbox a where<br>
type Repr a :: # -- gives size and alignment<br>
unbox :: a -> Repr a<br>
box :: Repr a -> a<br>
<br>
A problem with an instance (Unboxed a, Unboxed b) => Unboxed (a,b) is that it allows arbitrarily large unboxed values to be created at runtime. That doesn't work when you use specialization to create the needed info tables.</blockquote>
<div><br></div><div>As I mentioned further up in the email, I think this needs to be done at compile time. However, I'm not sure type classes are the right mechanism, as they don't guarantee that the polymorphism is resolved at compile time. Perhaps type families, in some form, is the right solution.</div>
<div><br></div><div>-- Johan</div><div><br></div></div>