Re: Alex and new Bool primops

9 Sep 2013

      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" 
Do: "Jan Stolarek" 
DW: "ghc-devs" 
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