[core libraries] RE: Alex and new Bool primops
Michael Snoyman
michael at snoyman.com
Tue Sep 10 15:37:55 UTC 2013
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>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] *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>
> 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] 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>
> | > Do: "Jan Stolarek" <jan.stolarek at p.lodz.pl>
> | > DW: "ghc-devs" <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
> | >> http://www.haskell.org/mailman/listinfo/ghc-devs
> | >
> |
> |
> | _______________________________________________
> | ghc-devs mailing list
> | 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.
> For more options, visit https://groups.google.com/groups/opt_out.****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130910/80bac75a/attachment.htm>
More information about the ghc-devs
mailing list