Having a requirement to manually install a newer Alex doesn't seem too onerous to me. That would be my recommendation.
On Tue, Sep 10, 2013 at 11:53 AM, Simon Peyton-Jones <simo...@microsoft.com>wrote: > (Simon M: are you ok with updating Alex? You were the one of those who > argued strongly for using the old names for the new primops.)**** > > ** ** > > The difficulty is this. **** > > **· **Alex generates Haskell code, by transforming Foo.x into > Foo.hs**** > > **· **The generated Foo.hs contains references to comparison > primops, say (>#) :: Int# -> Int# -> Bool**** > > **· **Therefore Foo.hs will not work with GHC 7.8 if we have > changed the type of (>#), which is what I think we have agreed to do.**** > > **· **The solution is to make Alex generates a Foo.hs that is > compilable either with GHC 7.8 or 7.6, by including enough CPP directives. > Alex already does this for compatibility with earlier GHCs**** > > **· **However, until there is a new version of Alex, you simply > won’t be able to bootstrap GHC 7.8 (or indeed the current HEAD).**** > > ** ** > > That’s all there is to it. It’s tiresome and trivial in a sense, but it’s > a choice we have to make.**** > > ** ** > > It might be perfectly reasonable to say **** > > **· **You can’t build GHC 7.8 from source with the Haskell > Platform until a new HP comes out with the new Alex (which will be soon).* > *** > > **· **Unless you install the new Alex manually**** > > ** ** > > This seems not too bad; people who build GHC from source are generally > pretty savvy. The choice between the two is what we seek your guidance on. > **** > > ** ** > > (Incidentally, a very similar situation has arisen for Happy: see > http://ghc.haskell.org/trac/ghc/ticket/8022. But there the cost of > perpetuating the status quo for another release cycle seems minimal.)**** > > ** ** > > Simon**** > > ** ** > > *From:* michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] *On > Behalf Of *Michael Snoyman > *Sent:* 10 September 2013 05:28 > *To:* Simon Peyton-Jones > *Cc:* core-libraries-commit...@haskell.org; ghc-devs; Geoffrey Mainland; > Jan Stolarek > *Subject:* Re: [core libraries] RE: Alex and new Bool primops**** > > ** ** > > I'll admit a fair amount of ignorance of the GHC build process. But > wouldn't it be standard that any tool used in the GHC build process itself, > and built by GHC itself, would need to have some conditional compilation in > place to handle API changes? It seems like the questions here are whether > we should ever allow breaking changes in the API, and in this case whether > the changes are coming too late in the development cycle. It seems like > we've agreed on the first count that it's beneficial to allow breaking API > changes. It could be that in this case we're too late in the dev cycle.*** > * > > ** ** > > In this case, it sounds like including the compatibility module in Alex > would be most expedient, but I'd defer to those who understand the process > better than me.**** > > ** ** > > On Mon, Sep 9, 2013 at 5:38 PM, Simon Peyton-Jones <simo...@microsoft.com> > wrote:**** > > Dear Core Libraries Committee > > I think we need your advice. > > This thread (mostly on ghc-devs) shows that if the shim-package and > boolean-primop decision goes as currently proposed, then we'll need a new > release of Alex > * Either to generate an import of GHC.Exts.Compat > (ie depend on the shim package) > * Or to make its own local tiny shim module for the primops it uses > * Or maybe some other plan > (Alex already has quite a bit of stuff designed to make it generate code > that will be compilable with a variety of GHCs.) > > Moreover this new release of Alex will be necessary simply in order to > allow 7.8 (or indeed 7.7) to be bootstrapped. So, for example, the current > HP could not be used to build GHC. > > How would you like us to proceed? Thanks!**** > > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of > | Geoffrey Mainland**** > > | Sent: 09 September 2013 16:14 > | To: Jan Stolarek > | Cc: ghc-devs > | Subject: Re: Alex and new Bool primops > |**** > > | I say this only somewhat facetiously, but this is *exactly* the sort of > | problem that the pro-backwards compatibility camp anticipates, and I > | mean the "pro-backwards compatibility camp" in the most general possible > | way :) The point is that you can never anticipate all the ways in which > | breaking backwards compatibility breaks things. How much "technical > | debt" is really accrued with backwards compatible primops? What is > | preventing us from doing the so-called "Right Thing" *after* the 7.8 > | release? > | > | Anyway, the one solution I can think of off the top of my head is to > | patch Alex's templates to use an #ifdef to pick primops based on the > | version of GHC being used for compilation. That will need to be done > | anyway. > | > | As an aside, I think any discussion that involves making decisions that > | effect the community as a whole should have a public mail archive. > | > | Geoff > | > | On 09/09/2013 11:02 AM, Jan Stolarek wrote: > | > I think the there was a general agreement in the committee that we > | should follow the best long-term solution, not the best short-term one. > | Here are two arguments (Plan B = break backwards compatibility): > | > > | > > I'd rather not hamstring GHC.* with a rats nest of backwards > | compatibility decisions, > | > > which all come at accreted costs, the mortgage for which is to be > | paid down forever > | > > by future development efforts. > | > > | > > I vote for plan B on the grounds that it's the Right Thing and the > | > > group that it breaks is both small and savvy. > | > > | > > [implementing backwards compatibility solution] only works once, > | though. We're in exactly the same boat on all future primop redesigns. > | > > | > There was also a decision of providing a backwards compatibility > | package that would make it easy for library authors to create packages > | that are compatible both with 7.6 and 7.8 (summarized here: > | http://www.haskell.org/haskellwiki/Compatibility_Modules). Sadly, > | there's no web archive for that list so I can't point you to the > | discussion. > | > > | > Anyway, this is clearly something no one has anticipated and the > | question is whether we have a good way to solve that problem? > | > > | > Janek > | > > | > ----- Oryginalna wiadomość ----- > | > Od: "Geoffrey Mainland" <mainl...@apeiron.net> > | > Do: "Jan Stolarek" <jan.stola...@p.lodz.pl> > | > DW: "ghc-devs" <ghc-devs@haskell.org> > | > Wysłane: poniedziałek, 9 wrzesień 2013 15:40:09 > | > Temat: Re: Alex and new Bool primops**** > > | > > | > Perhaps the core libraries committee should reconsider their decision? > | > :) Backwards compatibility is good. If HEAD implements the backwards > | > compatibility plan that Simon PJ and I suggested and said plan is > | > working, there should be a compelling reason to break compatibility > | and > | > have to go chasing down all the follow-on breakage (in, e.g., Alex) so > | > close to release. > | > > | > What was the committee's reasoning? > | > > | > Geoff > | > > | > On 09/09/2013 10:08 AM, Jan Stolarek wrote: > | >> I am refactoring new Bool primops (#6135). There was a discussion on > | core-libraries-commitee list and the decision was made that we should > | keep names of primops we used so far and change their type signature > | (right now HEAD has different names for new primops and reuses old names > | for compatibility wrappers). I've changed names of the primops and > | removed the wrappers but I can't bootstrap GHC because old primops are > | hardwired into Alex. I get this build error when attempting to build > | stage 2 compiler: > | >> > | >> compiler/stage2/build/Lexer.hs:2348:34: > | >> Couldn't match expected type 'Bool' with actual type 'Int#' > | >> In the first argument of '(&&)', namely '(offset >=# 0#)' > | >> In the expression: (offset >=# 0#) && (check ==# ord_c) > | >> In the expression: > | >> if (offset >=# 0#) && (check ==# ord_c) then > | >> alexIndexInt16OffAddr alex_table offset > | >> else > | >> alexIndexInt16OffAddr alex_deflt s > | >> > | >> compiler/stage2/build/Lexer.hs:2348:53: > | >> Couldn't match expected type 'Bool' with actual type 'Int#' > | >> In the second argument of '(&&)', namely '(check ==# ord_c)' > | >> In the expression: (offset >=# 0#) && (check ==# ord_c) > | >> In the expression: > | >> if (offset >=# 0#) && (check ==# ord_c) then > | >> alexIndexInt16OffAddr alex_table offset > | >> else > | >> alexIndexInt16OffAddr alex_deflt s > | >> > | >> And indeed, looking at Lexer.hs I see: > | >> > | >> alex_scan_tkn user orig_input len input s last_acc = > | >> (...) -- some irrelevant code here > | >> (!(new_s)) = if (offset >=# 0#) && (check ==# ord_c) > | >> then alexIndexInt16OffAddr alex_table > | offset > | >> else alexIndexInt16OffAddr alex_deflt s > | >> > | >> So to compile GHC, Alex would need to generate different code for GHC > | 7.6.3 and below, and different for GHC 7.7 and above (or alternatively > | it could generate #if pragmas), but this means we'd need to update Alex. > | I created compatibility module within GHC called ExtsCompat46 and tried > | adding it to list of imported modules, but in generated Lexer.hs Alex > | adds a bunch of other modules among which is GHC.Exts, which conflicts > | with import of ExtsCompat46: > | >> > | >> compiler/stage1/build/Lexer.hs:2349:41: > | >> Ambiguous occurrence `>=#' > | >> It could refer to either `ExtsCompat46.>=#', > | >> imported from `ExtsCompat46' at > | compiler/parser/Lexer.x:79:1-19 > | >> or `GHC.Exts.>=#', > | >> imported from `GHC.Exts' at > | compiler/stage1/build/Lexer.hs:75:1-15 > | >> (and originally defined in `ghc- > | prim:GHC.Prim') > | >> > | >> Again, we would need updated version of Alex to generate correct code > | (also, this would break in the future after removing that compatibility > | module). I don't see a way out of this. Help? > | >> > | >> Janek > | >> > | >> _______________________________________________ > | >> ghc-devs mailing list > | >> ghc-devs@haskell.org > | >> http://www.haskell.org/mailman/listinfo/ghc-devs > | > > | > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs@haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > > -- > You received this message because you are subscribed to the Google Groups > "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-core-libraries+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.**** > > ** ** >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
