Broken Data.Data instances
Simon Peyton Jones
simonpj at microsoft.com
Thu Jul 24 16:22:03 UTC 2014
GHC's data structures are often mutually recursive. e.g.
* The TyCon for Maybe contains the DataCon for Just
* The DataCon For just contains Just's type
* Just's type contains the TyCon for Maybe
So any attempt to recursively walk over all these structures, as you would a tree, will fail.
Also there's a lot of sharing. For example, every occurrence of 'map' is a Var, and inside that Var is map's type, its strictness, its rewrite RULE, etc etc. In walking over a term you may not want to walk over all that stuff at every occurrence of map.
Maybe that's it; I'm not certain since I did not write the Data instances for any of GHC's types
Simon
From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of p.k.f.holzenspies at utwente.nl
Sent: 24 July 2014 16:42
To: ghc-devs at haskell.org
Subject: Broken Data.Data instances
Dear GHC-ers,
Is there a reason for explicitly broken Data.Data instances? Case in point:
> instance Data Var where
> -- don't traverse?
> toConstr _ = abstractConstr "Var"
> gunfold _ _ = error "gunfold"
> dataTypeOf _ = mkNoRepType "Var"
I understand (vaguely) arguments about abstract data types, but this also excludes convenient queries that can, e.g. extract all types from a CoreExpr. I had hoped to do stuff like this:
> collect :: (Typeable b, Data a, MonadPlus m) => a -> m b
> collect = everything mplus $ mkQ mzero return
>
> allTypes :: CoreExpr -> [Type]
> allTypes = collect
Especially when still exploring (parts of) the GHC API, being able to extract things in this fashion is very helpful. SYB's "everything" being broken by these instances, not so much.
Would a patch "fixing" these instances be acceptable?
Regards,
Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140724/f55478f8/attachment.html>
More information about the ghc-devs
mailing list