Hi

> > That approach worries me.  We could add generic traversals all over the
>  > place, and while none of them is a "bottleneck", the overall effect could 
> be
>  > quite significant.
>
> I recently added Data and Typeable instance to all AST datatypes
>  directly in the code of GHC, the compilation time didn't seem affected
>  by this addition. Of course I didn't try to add Uniplate, Term ...
>  instances as well.

I think Simon's point is that using Data instances to write a
transformation pass will be slower than writing the transformation
directly. He is nearly certainly right. However, I think that Data
instances will be used outside of GHC by GHC API users first, and by
the time it starts to take hold within GHC we'll know the answer
(which may be that there is no problem, or that everyone should use
some hypothetical Uniplate++ with added RULE goodness ;-) )

>  > The right approach I believe is to keep an eye on compile times when making
>  > these kind of changes, and if at any point the compiler slows down by a few
>  > percent, then back off.  Timing a compile of GHC itself is good for this.

This sounds like a good piece of information to have on a nightly
basis so any trends can be measured. It could come in handy for other
things.

Thanks

Neil

_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to