[core libraries] RE: Alex and new Bool primops
Geoffrey Mainland
mainland at apeiron.net
Tue Sep 10 16:05:14 UTC 2013
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
> <simonpj at microsoft.com <mailto:simonpj at 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.snoyman at gmail.com
> <mailto:michael.snoyman at gmail.com>
> [mailto: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
> <mailto: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