Dear Simon, et al,
These are very good points to make for people writing such traversals
and queries. I would be more than happy to write a page on the pitfalls
etc. on the wiki, but in my experience so far, exploring the innards of
GHC is tremendously helped by trying small things out and showing (bits
of) the intermediate structures. For me, personally, this has always
been hindered by the absence of good instances of Data and/or Show (not
having to bring DynFlags and not just visualising with the pretty
printer are very helpful).
So... does anyone object to me changing these "broken" instances with
the ones given by DeriveDataTypeable?
Also, many of these internal data structures could be provided with
useful lenses to improve such traversals further. Anyone ever go at
that? Would be people be interested?
Regards,
Philip
Simon Peyton Jones <mailto:simo...@microsoft.com>
24 Jul 2014 18:22
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-boun...@haskell.org] *On Behalf Of
*p.k.f.holzensp...@utwente.nl
*Sent:* 24 July 2014 16:42
*To:* ghc-devs@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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
