However, until this fundamental issue is addressed, is there any
way to make GHC Api clients less dependent on the details of a specific
GHC Api version? In the scenario given above, if T,
despite being built with GHC V1, was able to work with GHC
V2's Api, then it could use GHC V2's formats describing the
libraries/packages needed by H. But that means (a) abstraction
from the rapidly changing GHC Api, to get a stable sub-interface,
I wonder if Template Haskell provides this already, in some form?
I'm not sure I understand what you mean, other than that TH uses
the same parser as GHC, but not the same AST. The translation
of GHC Ast into TH Ast does provide some stability against changes
in GHC Ast administrative details, but it also isolates TH from
actual changes in GHC syntax: just because GHC can parse
type functions, that doesn't mean that TH can work with them.
It is, however, an interesting use case of the advantages and
disadvantages arising from providing an extra level of abstraction
over the GHC Api types. And it would be useful to know whether
the lessons learned from TH could be incorporated into an
improved design for such an abstraction - one that hides only
the details, not the essence (we don't want to wait for TH to
follow GHC syntax extensions - they should translate implicitly;
we just don't want TH Asts to change whenever the GHC
Asts are refactored).
But I suspect that such abstractions would be client-specific.
Taking the example of type functions:
- TH needs all the details about type functions
- Haddock only needs to know that type functions are
class-like for most purposes, together access to the names
involved that might have comments attached to them, and
some tag that says "this type-class-like thing is a type function",
so that rendering can be optimised
Ok, I guess I do understand why you mentioned TH, after all!-)
Thanks,
Claus
Perhaps it would need to be extended, even to allow you to break
abstraction (so that while type-functions are in flux, and we aren't
ready to add them to the stable TH API, Haddock could consciously use
ifdefs or something to get at the specific GHC 6.10 representation).
I'm sure there are all kinds of problems with this idea, including that
TH isn't actually entirely stable! and it might be impossible. -- but if
it's useful then TH would get some more love, which could make its
existing clients happier too...
-Isaac
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
