Hi GHC Hackers,as many of you know, my GSoC project was to improve the GHC API. I'm not quite sure how useful the result actually is. It brings some changes for the better, but at quite a big price:
*** All GHC API clients will break ***.
The changes are described in a bit more detail at [1], but here's the
big picture:
[1]: http://hackage.haskell.org/trac/ghc/wiki/GhcApiStatus
1. Almost all GHC API functions have a signature like this:
f :: GhcMonad m => ... -> m X
API users can declare the proper instance for their custom
monad. (A default 'Ghc' monad is provided and I will possibly add a
'GhcT' monad transformer.)
2. GHC API functions signal errors (including compilation errors) using extensible exceptions.
To handle these exceptions, I added a class 'ExceptionMonad' that allows handling extensible exceptions. (This should eventually become part of some standard library.)
The big question now is: Are these changes worth a complete API break?There is some work left to verify that the behaviour is actually the same. In particular the restructuring may silently drop some error messages (but the testsuite should find most of those cases) and I have to verify that the -Werror option is treated properly.
Either of these changes will break clients, so it's better to add them both at the same time. In principle it should be possible to provide a compatibility layer by creating wrappers like this:
oldApiFn :: Session -> Y -> IO (Maybe X)
oldApiFn s y =
runGhc s $
newApiFn y >>= return . Just
`gcatch` $ \(e :: SourceOrGhcApiError) -> do
printAllErrorsAndWarnings e
return Nothing
That would be a lot of work, though, which I'd rather spend on
ensuring that the new API behaves the same.
While we're breaking things, we can go ahead and clean up some other things, too, like hierarchical module names (other ideas? :) ). A big, big issue is the short time to the next release, though.
The changes are not very local so maintaining it as a branch until the next release is a big task, because there will be a lot of conflicts with upstream. However, if the change is considered too big/short notice, I could do it.
Thoughts? / Thomas -- Push the envelope. Watch it bend.
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
