Ross, Malcolm, Ralf

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?

Simon

| -----Original Message-----
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of
| [EMAIL PROTECTED]
| Sent: 19 January 2005 22:34
| To: [EMAIL PROTECTED]
| Subject: 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
| 
| ralf        2005/01/19 14:33:37 PST
| 
|   Modified files:
|     libraries/base/Data  Array.hs FiniteMap.hs IntMap.hs IntSet.hs
|                          Map.hs Set.hs Typeable.hs
|     libraries/base/Data/Generics Instances.hs
|     libraries/base/GHC   Conc.lhs ForeignPtr.hs
|   Log:
|   Added quite a few more Data instances.
| 
|   For these datatypes:
| 
|   - Data.Array
|   - Data.FiniteMap
|   - Data.IntMap
|   - Data.IntSet
|   - Data.Map
|   - Data.Set
|   - GHC.ST
|   - GHC.ForeignPtr
|   - Control.Concurrent.MVar and friends
| 
|   (In some cases, this also required adding Typeable instances.)
| 
|   Most or all additions have been tagged by
|   #ifdef __GLASGOW_HASKELL__ ...
| 
|   For the _abstract_ datatypes in the above list,
|   we use the from... and to... projections and injections
|   so that we can process the containers or whatever as lists.
|   We don't provide the reflection API for abstract datatypes.
| 
|   If anyone sees Data-wanting datatypes in the base or elsewhere
|   in the module space, please let me know, or please go ahead,
|   and add coverage for SYB. As far as I understand, the base
|   code cannot use "deriving (Typeable, Data)", whereas this
|   is very well an option for non-base modules. Indeed it is
|   readily done like this in:
|   - network/Network/URI
|   - haskell-src
| 
|   Revision  Changes    Path
|   1.12      +18 -2     fptools/libraries/base/Data/Array.hs
|   1.21      +21 -0     fptools/libraries/base/Data/FiniteMap.hs
|   1.6       +22 -0     fptools/libraries/base/Data/IntMap.hs
|   1.8       +22 -0     fptools/libraries/base/Data/IntSet.hs
|   1.5       +22 -0     fptools/libraries/base/Data/Map.hs
|   1.13      +22 -0     fptools/libraries/base/Data/Set.hs
|   1.32      +2 -1      fptools/libraries/base/Data/Typeable.hs
|   1.5       +57 -0
fptools/libraries/base/Data/Generics/Instances.hs
|   1.32      +11 -0     fptools/libraries/base/GHC/Conc.lhs
|   1.18      +0 -4      fptools/libraries/base/GHC/ForeignPtr.hs
| _______________________________________________
| Cvs-libraries mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/cvs-libraries
_______________________________________________
Cvs-libraries mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-libraries

Reply via email to