f x y | Just a <- x, Right a' <- y = foo
| Left b <- y = bar
| otherwise = baz
gets translated to
f x y = case x of
Just a -> case y of
Right a' -> foo
Left b -> bar -- 'a' renamed inside 'bar'
_ -> case y of
Left b -> bar -- note
_ -> baz
Here, bar is duplicated and possibly modified, so the following
translation is preferred but not guaranteed:
f x y = case x of
Just a -> case y of
Right a' -> foo
Left b -> bar' b
_ -> case y of
Left b -> bar' b
_ -> baz
where bar' b = bar
At this point locations between both versions do not match. You have
to be very careful how you design the interface to the refactorings
and how you rewrite the code as the result of a refactoring, i.e.,
renaming 'y' may work or not depending on the method used. It is,
however, sufficient if the tool only needs to analyse, not transform,
the code.
However, a fold-based interface may put less constraints on portability -- only function calls need to be portable, not data representations. However, you might have to transitively redefine lots of used data types as well this won't be practical either. API users could import a specific version, say GHC_6_8 and we could provide backwards compatibility for some cases by translating some parts of GHC_6_10 into GHC_6_8 datatypes and fail for cases where this is not possible.
On Thu, Jul 17, 2008 at 6:06 PM, Claus Reinke <[EMAIL PROTECTED]> wrote:
However, until this fundamental issue is addressed, is there anyway to make GHC Api clients less dependent on the details of a specificGHC 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 whetherthe lessons learned from TH could be incorporated into an improved designfor 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, ClausPerhaps it would need to be extended, even to allow you to breakabstraction (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 orsomething 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 existingclients happier too... -Isaac_______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
/ Thomas --My shadow / Change is coming. / Now is my time. / Listen to my muscle memory. / Contemplate what I've been clinging to. / Forty-six and two ahead of me.
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
