cvs commit: fptools/libraries/base/Data Array.hs FiniteMap.hs IntMap.hs IntSet.hs Map.hs Set.hs Typeable.hs fptools/libraries/base/Data/Generics Instances.hs fptools/libraries/base/GHC Conc.lhs ForeignPtr.hs

[ross at soi.city.ac.uk]

On Tue, Feb 01, 2005 at 08:57:46AM -0000, Simon Peyton-Jones wrote:
> In fact GHC is quite happy to derive Data and Typeable even for
> base-package modules, provided Data.Generics and Data.Typeable can be
> imported.
> 
> But I don't want to mess up NHC and Hugs by making this change.  What
> the deal?
> 
> I think Hugs understands Typeable, but can't derive instances thereof;
> therefore it might be easier to avoid 'deriving( Typeable )' in any
> library Hugs wants to grok.  Is that right?  What about nhc?
> 
> I think that neither Hugs nor NHC grok the Data class, so we can use
> 'deriving( Data )' freely (surrounded with #ifdef __GLASGOW_HASKELL__,
> of course).  Is that right?

Yes, Hugs can't derive either of them.  Typeable instances are useful
for Data.Dynamic, so we do those using the INSTANCE_TYPEABLEn macros
from Typeable.h.  (This is only available in base -- maybe we should
promote it.)  Hugs could handle the Data class in non-H98 mode, but
it's not much use without instances, which are a bit harder to define.

So this sort of thing should be fine with Hugs and (I think) Nhc98:

import Data.Typeable
#ifdef __GLASGOW_HASKELL__
import Data.Generics.Basics
import Data.Generics.Instances
#else
#include "Typeable.h"
#endif

...

data Set a    = Tip 
              | Bin {-# UNPACK #-} !Size a !(Set a) !(Set a)
#ifdef __GLASGOW_HASKELL__
        deriving (Typeable, Data)
#else
INSTANCE_TYPEABLE1(Set,setTc,"Set")
#endif