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
