#ifdef considered harmful (was: DData)

[Simon Marlow]

On 19 April 2004 15:06, Jan-Willem Maessen - Sun Labs East wrote:

> The real problem, of course, isn't the data structures at all---GHC
> does an excellent job with these (though the "UNPACK" pragma is a
> revelation).  The actual problem is function arguments.  GHC can't do
> worker-wrapper unless a function is strict.  Often we end up with
> something like this:

I'm not sure I'd characterise that as "the real problem" - in a lot of
the cases I've come across, the UNPACK pragma has been exactly what I
needed.  In a few critical functions where I found that arguments
weren't strict enough, I've had to add seqs to help the compiler.

> data Tree a = Branch !Int a (Tree a) (Tree a)
> 
> lookfor :: Int -> Tree a -> Maybe a
> lookfor Leaf key = Nothing
> lookfor (Branch k v l r) key
>    | key==k    = Just v
>    | key < k   = lookfor l key
>    | otherwise = lookfor r key
> 
> Here we don't use "key" in the first clause, so GHC isn't allowed to
> unbox.  Most of the uses of Int# that I've seen in library code have
> been workarounds to this problem.  In this case, being able to write
> 
> lookfor :: FastInt -> Tree a -> Maybe a
> 
> might give us some hope of getting the compiler to generate the
> unboxed code we might want, yet still afford us the opportunity to
> use boxed types if that's not possible.
> 
> We could do this today without changing the language or the compilers.
> The library would have to be carefully coded...

I'm not clear on exactly what the FastInt type means.  I think I asked
Alastair the same question recently - is FastInt an unlifted type?  Can
I store it in a polymorphic data structure or pass it to a polymorphic
function?

If FastInt is Int# in GHC, and we want it to be portable, then we have
to introduce unlifted types & kinds in Hugs and nhc98 too.  Declaring
instances of classes for unlifted types isn't possible, so you can't
have instane Num Int#, for example.  I think you need polymorphic kinds
for that.

Cheers,
	Simon