Generic tries (long)

Isaac Dupree isaacdupree at
Mon Jun 23 08:28:59 EDT 2008

>> Also, as others mentioned, using Int# in an API is not great because
>> this is a GHC internal type.  If you found situatuins where GHC is not
>> unboxing something please send a mail to the GHC team---they are
>> usually very good at fixing these sorts of things.  Adrian mentioned
>> that you use CPP to control the use of Int# but this does not help if
>> the Int# leaks through the API:  (i) I could still have programs that
>> work in Hugs and fail to compile in GHC (and vice versa), (ii) if I
>> want to use your map library, I would have to compile all my programs
>> with the CPP extensions, which is not nice.
> Well I may be wrong, but AFAIK as we're talking about a class method
> here if boxed is what you specify, boxed is what you will get. It
> *might* be converted to unboxed if you use a SPECIALISE pragma, but
> this kind of optimisation depends on strictness analysis. It's very
> easy to end up writing something that is non-strict (or is strict but
> ghc can't see it) and lose the unboxing.

this is where we need, hmm,
if in the class there was
size :: map a -> Int#
one would like something such as
size :: map a -> {-# UNPACK #-} Int
to work, since that unboxing doesn't change the semantics (results are 
implicitly lifted...).
But as it is
addSize :: map a -> UINT -> UINT
foldElemsUINT :: (a -> UINT -> UINT) -> map a -> UINT -> UINT
we also need something like John Meacham's ! and ~ stuff in class 
methods, to force strictness (because that changes the semantics).  It 
could get ugly, since GHC tries to preserve sharing by default, so we 
always need UNPACK:
addSize :: map a -> {-#UNPACK#-}!Int -> {-#UNPACK#-}Int

Reminds me a little of
because functions in data and in classes suffer the same "openness" 
problem that you can't know, given separate compilation, what functions 
are going to be used to implement that - so you can't optimize for them 
so well.


More information about the Libraries mailing list