We can definitely add those to the existing data types, but it
wouldn't be entirely trivial. I believe some of them already have
Read and Show instances which don't do quite what we want, and
changing them to automatically-derived instances might make other
bits of the compiler behave differently. Mostly, this would probably
just affect debugging output, and might be fine.
More importantly, though, GHC's data structures contain a lot of
internal representation details that we probably don't want to
include in a generic external format, partly because they change
quite frequently. At least, that's how I've been thinking about it.
Maybe it would be fine to include those details. If we do, however,
we're essentially duplicating .hi files. Since they have a mechanism
for inlining, they could theoretically include all of the function
bodies from the source file. It might be easier to just allow
creation of "complete" .hi files, which contain inlining information
for all functions, not just those deemed practical for inlining.
Aaron
On Jun 17, 2007, at 12:08 PM, Tim Chevalier wrote:
There's nothing to stop us from just adding deriving(Show) and
deriving(Read) to those existing data types, right? Of course, this
requires adding instances for a number of data types. I guess the real
problem is that someone such as Neil who wants to read in the
resulting code would have to import a lot of code from GHC.
Cheers,
Tim
--
Tim Chevalier* [EMAIL PROTECTED] *Often in error, never
in doubt
"Unfortunately, there is no algorithm for making human
relationships work."
-- Robin Williams
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
