Sounds reasonable to me. Geoff
On 9/10/13 11:37 AM, Michael Snoyman wrote: > 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 <mailto: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> > [mailto: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 > <mailto: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 <mailto: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 > <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 > <mailto:mainl...@apeiron.net>> > | > Do: "Jan Stolarek" <jan.stola...@p.lodz.pl > <mailto:jan.stola...@p.lodz.pl>> > | > DW: "ghc-devs" <ghc-devs@haskell.org > <mailto: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 <mailto:ghc-devs@haskell.org> > | >> http://www.haskell.org/mailman/listinfo/ghc-devs > | > > | > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs@haskell.org <mailto: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 > <mailto:haskell-core-libraries%2bunsubscr...@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
