First idea: instead of rejecting unpack pragmas on polymorphic fields, have
them require a class constraint on the field types. Example:
data UnboxPair a b = (Unbox a, Unbox b) => UP {-# UNPACK #-} !a {-# UNPACK
#-} !b
The Unbox type class would be similar in spirit to the class with the s
> 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.
>
There i
On Sat, Mar 3, 2012 at 8:06 AM, Twan van Laarhoven wrote:
> 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.
>
> It might be possible to esse
On 03/03/12 01:40, Johan Tibell wrote:
Hi all,
These ideas are still in very early stages. I present them here in hope
of starting a discussion. (We discussed this quite a bit at last year's
ICFP, I hope this slightly different take on the problem might lead to
new ideas.)
I think the next big
+1 !
On Fri, Mar 2, 2012 at 7:40 PM, Johan Tibell wrote:
> Hi all,
>
> These ideas are still in very early stages. I present them here in hope of
> starting a discussion. (We discussed this quite a bit at last year's ICFP,
> I hope this slightly different take on the problem might lead to new i
Hi all,
These ideas are still in very early stages. I present them here in hope of
starting a discussion. (We discussed this quite a bit at last year's ICFP,
I hope this slightly different take on the problem might lead to new ideas.)
I think the next big step in Haskell performance is going to c
