[core libraries] RE: Alex and new Bool primops
Simon Marlow
marlowsd at gmail.com
Wed Sep 11 15:52:34 UTC 2013
On 10/09/13 09:53, Simon Peyton-Jones wrote:
> (Simon M: are you ok with updating Alex?
Yes I am. GHC's configure script also needs to be fixed to detect an
old version of Alex and tell the user what to do.
Cheers,
Simon
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.snoyman at gmail.com [mailto:michael.snoyman at gmail.com] *On
> Behalf Of *Michael Snoyman
> *Sent:* 10 September 2013 05:28
> *To:* Simon Peyton-Jones
> *Cc:* core-libraries-committee at 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
> <simonpj at microsoft.com <mailto:simonpj at 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-bounces at haskell.org
> <mailto:ghc-devs-bounces at 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" <mainland at apeiron.net
> <mailto:mainland at apeiron.net>>
> | > Do: "Jan Stolarek" <jan.stolarek at p.lodz.pl
> <mailto:jan.stolarek at p.lodz.pl>>
> | > DW: "ghc-devs" <ghc-devs at haskell.org <mailto:ghc-devs at 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 at haskell.org <mailto:ghc-devs at haskell.org>
> | >> http://www.haskell.org/mailman/listinfo/ghc-devs
> | >
> |
> |
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org <mailto:ghc-devs at 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+unsubscribe at googlegroups.com
> <mailto:haskell-core-libraries%2Bunsubscribe at googlegroups.com>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
More information about the ghc-devs
mailing list