Data and Typeable instances for GenericPackageDescription
jpmoresmau at gmail.com
Thu Jun 17 11:43:11 EDT 2010
On Thu, Jun 17, 2010 at 1:21 AM, Duncan Coutts <duncan.coutts at googlemail.com
> On Tue, 2010-06-15 at 20:43 +0200, JP Moresmau wrote:
> > Hello, I was wondering if there are instances for Typeable and Data
> > available somewhere for GenericPackageDescription. Automatic deriving
> > fails, probably, if I read the docs right, because some types in there
> > have more than 7 parameters. It would help me to use the cabal file
> > parsing functions and convert the result automatically to JSON for use
> > in Eclipse through Scion. Of course if there isn't I suppose I can
> > write my own instances and maybe share them with who ever is
> > interested.
> I'm happy to accept patches.
> One thing to keep in mind is that the Cabal library must be compilable
> with hugs and nhc98 as well as ghc. I think that means we cannot use
> deriving Typeable or Data since, as far as I know, neither of those
> compilers supports that language extension.
> Note that the ModuleName constructor is not exported on purpose. Do Data
> instances make sense for abstract types?
Yes, I've managed to specify a Data instance for ModuleName without touching
the Cabal source code (using fromString instead of a constructor). So I can
either do them by end for all of them and put that in the Cabal code, and
test for every supported compiler, or we can just put the instances (the
explicit ModuleName and the derive generated ones for all the other) in a
separate library that people can use when they need that functionality, that
can require all these dependencies that we don't want Cabal to have (TH +
derive). Second option is easier (-: I can tell from hackage that it's not
unusual to have libraries only providing instances.
As an aside, ModuleName is the only problematic constructor in 1.8 or 1.9,
as far as I can tell.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cabal-devel