On 29 Aug 2008, at 10:37, Claus Reinke wrote:
This darcs2 style of announcements seems to be infective. Yourmessage sounds as if you'd like someone to tell you that no, you shouldn't really merge?-)1. Going directly from not-even-in-head to in-release-candidate sounds scary, especially if it is going to be the only alternative, with no compatibility fallback, right at the core of ghc.2. Have you converted, bootstrapped and tested the core ghc api clients (ghc, ghci, haddock), do they still build and pass all their tests? Without this, merging your code would prevent a release. With this, you should have some data wrt difficulty, confidence, and benefits.3. If you're going to break all ghc api clients, at least your selfshould be convinced that we're getting something very good out of it - my understanding from early versions of your codewas that you're: a splitting compiler phases b making implicit session monads explicit c cleaning up and unifying error handling d trying out some changes enabled by a-c a-c sounded like useful and incremental improvements, withonly d anything to worry about. Now you're saying that a-d are so intertwined that the whole is neither incremental nor are you yourself convinced it is all that useful?4. "we can throw in more breaking changes, to make the messbigger" - you're not seriously suggesting this as a "pro" argument?-)So, since you asked for it: no, you shouldn't merge your code - things would go wrong horribly, and nothing can be worth that!-) Now, your task is (a) to convince everyone that things wouldn't go wrong (at least 2 above), (b) that there are clear advantagesof doing everything your way (backed up with data from 2), and (c) there are (temporary) fallback options for those who do not want to adapt to your changes immediately.Is this what you wanted to hear?-) Claus
Ok let me rephrase.-- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< -----
____ _ _ ____ __ _____ _ ./\/\/\,
/ __ \ | | | | / __ \ / \ | __ \ | |< BETA >
| | |_| | | | | | | |_| / /\ \ | | | | | | `\/\/\/`
| | __ | '--' | | | | |__| | | |__| | | |
| | |. | | .--. | | | _ | .__. | | .___/ | |
| |__| | | | | | | |__| | | | | | | | | |
\____/ |_| |_| \____/ |_| |_| |_| |_|
=====================================================================
Awsome new GHC API 2.0 BETA ready for merge! - Details at eleven[11]!
=====================================================================
If we merge NOW, we will have fixed all remaining bugs, until 6.10.2!
What do you get?
1. Support for fashioned custom monads! No longer:
do session <- getSession
r <- io $ GHC.apiCall session blah
Just simple:
r <- GHC.apiCall blah
With only one(*) instance (of GhcMonad) you're ready to go!
2. Extensible exceptions everywhere! No more:
mb_rslt <- io $ GHC.apiCall session blah
case mb_rslt of
Nothing -> mixInSomeErrorHandling
Just rslt -> do
mb_other_rslt <- io $ GHC.apiCall2 session blerb rslt
case mb_other_rslt of
Nothing -> mixInSomeMoreErrorHandling
Just other_rslt -> ...
Just simple:
rslt <- GHC.apiCall blah
other_rslt <- GHC.apiCall2 blerb rslt
`gcatch` $ \(e :: SourceError) ->
doCentralisedErrorHandlingeHere
3. No more overriding log_action! Errors can be extracted from
exceptions and warnings can be read using the API call getWarnings
and cleared using clearWarnings. You can also provide another
Warning logger.
thefineprint: (to read this please step away from your computer at least 2 meters, it is supposed to be in very small font) (*) An instance of GhcMonad will also require instances for WarnLogMonad, MonadIO and ExceptionMonad. If you embed the Ghc monad into your own monad or use the GhcT monad transformers these can be achieved by simple lifting or come for free respectively.
4. If this feature is merged into GHC 6.10.1 it will break practically every existing API client. Depending on how that client is structured these changes will be straightforward, but cross-cutting.
5. A compatibility layer is possible, but requires some work. [11]: http://hackage.haskell.org/trac/ghc/wiki/GhcApiStatus-- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< -----
Better? Regarding the other questions:(1) Ok, thinking about it, it would probably Ok to merge it in after the 6.10 branch, but then backporting changes to 6.10 would become very difficult. Maintaining it as a long-running branch would be involving, though.
(2) I have converted GHCi and GHC. stage2 runs. --interactive works. The test suite shows some failures, but most of them are related to the same two or three remaining bugs. I am more concerned about bugs not shown by the test suite and rough edges of the API.
(3a) can be done independently if we opt against these changes (4) well, it's certainly a bit short before the release.So, I could backport the other changes (split-up phases) and could merge the rest some time after the 6.10 branch.
-- Stop pushing that envelope. The mac will break.
I don't care, I'd much rather buy a ThinkPad for the same money. / Thomas -- Still trying to push that envelope... http://www.phrases.org.uk/meanings/push-the-envelope.html http://toolshed.down.net/lyrics/lateraluslyrics.php#09
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
