- ghc-devs - Haskell.org

Validate fails for current master
by Simon Hengel 14 Sep '13

14 Sep '13

Hi, I'd love to push some Haddock changes, but for me validate on current master fails with: 1 caused framework failures 1 unexpected passes 86 unexpected failures Errors are of the form: - Multi-way if-expressions need MultiWayIf turned on + Multi-way if-expressions need -XMultiWayIf turned on Is one of you guys looking into this? Cheers, Simon

2 3

Data kind syntax
by Simon Peyton-Jones 13 Sep '13

13 Sep '13

Trevor Thanks for working on the data-kind stuff. I've had a terribly crammed week, so I have only just looked at it properly. The first thing I look for is a wiki page articulating the design you have chosen. I think it's this: http://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindsWithoutData Is that it? By which I mean, are there really *zero* wrinkles, dark corners? Second, I'm not so happy about introducing a whole new constructor, KindDecl, in TyClDecl; plus associated clobber like a new data type TyConDecl. That brings lots of new code to treat those new declarations. All that new code makes sense for things that differ radically -- for example a class declaration is very different to a data type declaration. BUT this 'data kind' stuff is really very very similar to an ordinary data type declaration! You just treat a very restricted form. Moreover, it won't be long before Stephanie and Richard are seeking GADTs at the kind level, and then you'll have to expand it, duplicating yet more code. One way to recover the commonality would be to really treat it as a data type declaration, but to restrict what is actually brought into scope (just as 'data type' will do). But then what about the use of '*' in data kind? data kind T = A * | B T T Well, that's really just a parsing issue! The parser can parse it as a kind, so that it understands the star correctly. But having parsed it, we can treat it largely like an ordinary data type declaration, can't we? What do you think? Want to Skype? Sadly I'm out Mon/Tues. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 09 September 2013 04:54 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] data-kind-syntax: Fix how we're using roles with | `data kind` declarations (13d4096) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : data-kind-syntax | Link : | http://ghc.haskell.org/trac/ghc/changeset/13d4096e0668e9f80a8601122affc6 | 4f8be295de/ghc | | >--------------------------------------------------------------- | | commit 13d4096e0668e9f80a8601122affc64f8be295de | Author: Trevor Elliott <trevor(a)galois.com> | Date: Sun Sep 8 17:46:48 2013 -0700 | | Fix how we're using roles with `data kind` declarations | | | >--------------------------------------------------------------- | | 13d4096e0668e9f80a8601122affc64f8be295de | compiler/iface/IfaceSyn.lhs | 11 +++++++---- | compiler/iface/MkIface.lhs | 3 ++- | compiler/iface/TcIface.lhs | 5 +++-- | compiler/typecheck/TcTyClsDecls.lhs | 15 ++++++++------- | compiler/types/TyCon.lhs | 8 ++++---- | 5 files changed, 24 insertions(+), 18 deletions(-) | | diff --git a/compiler/iface/IfaceSyn.lhs b/compiler/iface/IfaceSyn.lhs | index b12906b..ca772ac 100644 | --- a/compiler/iface/IfaceSyn.lhs | +++ b/compiler/iface/IfaceSyn.lhs | @@ -436,19 +436,22 @@ instance Binary IfaceBang where | | data IfaceTyConDecl | = IfTyCon { | - ifTyConOcc :: OccName, -- constructor name | - ifTyConArgKs :: [IfaceKind] -- constructor argument kinds | + ifTyConOcc :: OccName, -- constructor name | + ifTyConArgKs :: [IfaceKind], -- constructor argument kinds | + ifTyConRoles :: [Role] -- constructor argument roles | } | | instance Binary IfaceTyConDecl where | - put_ bh (IfTyCon a1 a2) = do | + put_ bh (IfTyCon a1 a2 a3) = do | put_ bh (occNameFS a1) | put_ bh a2 | + put_ bh a3 | get bh = do | a1 <- get bh | a2 <- get bh | + a3 <- get bh | occ <- return $! mkOccNameFS tcName a1 | - return (IfTyCon occ a2) | + return (IfTyCon occ a2 a3) | | data IfaceClsInst | = IfaceClsInst { ifInstCls :: IfExtName, -- See | comments with | diff --git a/compiler/iface/MkIface.lhs b/compiler/iface/MkIface.lhs | index 6764c91..3fff2b8 100644 | --- a/compiler/iface/MkIface.lhs | +++ b/compiler/iface/MkIface.lhs | @@ -1566,7 +1566,8 @@ tyConToIfaceDecl env tycon | | ifaceTyConDecl ty_con | = IfTyCon { ifTyConOcc = getOccName (tyConName ty_con), | - ifTyConArgKs = map (tidyToIfaceType emptyTidyEnv) | args } | + ifTyConArgKs = map (tidyToIfaceType emptyTidyEnv) | args, | + ifTyConRoles = tyConRoles ty_con } | where | (args,_) = splitFunTys (tyConKind ty_con) | | diff --git a/compiler/iface/TcIface.lhs b/compiler/iface/TcIface.lhs | index d6b6a55..2d18a74 100644 | --- a/compiler/iface/TcIface.lhs | +++ b/compiler/iface/TcIface.lhs | @@ -668,11 +668,12 @@ tcIfaceDataCons tycon_name tycon _ if_cons | ; return (HsUnpack (Just co)) } | | tcIfaceTyConDecl :: Kind -> KCon -> IfaceTyConDecl -> IfL TyCon | -tcIfaceTyConDecl kind kcon IfTyCon { ifTyConOcc = occ_name, | ifTyConArgKs = args } | +tcIfaceTyConDecl kind kcon IfTyCon { ifTyConOcc = occ_name, | ifTyConArgKs = args, | + ifTyConRoles = roles } | = do name <- lookupIfaceTop occ_name | -- See the comment in tc_con_decl of tcIfaceDataCons for why | forkM | kinds <- forkM pp_name (mapM tcIfaceKind args) | - return (mkDataKindTyCon kcon name (mkFunTys kinds kind)) | + return (mkDataKindTyCon kcon name (mkFunTys kinds kind) roles) | where | pp_name = ptext (sLit "Type constructor") <+> ppr occ_name | | diff --git a/compiler/typecheck/TcTyClsDecls.lhs | b/compiler/typecheck/TcTyClsDecls.lhs | index 99a3584..d348e8b 100644 | --- a/compiler/typecheck/TcTyClsDecls.lhs | +++ b/compiler/typecheck/TcTyClsDecls.lhs | @@ -118,7 +118,7 @@ tcTyAndClassDecls boot_details tyclds_s | -- remaining groups are typecheck in the extended global | env | | tcTyClGroup :: ModDetails -> TyClGroup Name -> TcM TcGblEnv | -tcTyClGroup boot_details decls | +tcTyClGroup _boot_details decls | | all (isKindDecl . unLoc) decls | = do (kcons, _) <- fixM $ \ ~(_, conss) -> do | let rec_info = panic "tcTyClGroup" "rec_info" | @@ -820,13 +820,12 @@ mkKindCon _rec_info tycons KindDecl { tcdLName = | L _ kind_name | kind_name | sKind | kvars | - [] -- XXX roles here? | + (replicate (length kvars) Nominal) -- no interesting kind | equality | Nothing | [] | (DataKindTyCon tycons) | NoParentTyCon | - -- TODO, make the rec_info work | - NonRecursive --(rti_is_rec rec_info kind_name) | + NonRecursive -- XXX is this OK? | False | NotPromotable | where | @@ -838,8 +837,8 @@ mkKindCon _ _ _ = | panic "mkKindCon" "non 'data kind' declaration" | | tcKindDecl :: RecTyInfo -> TyClDecl Name -> TcM [TyCon] | -tcKindDecl rec_info KindDecl { tcdLName = L _ kind_name, tcdKVars = | lknames | - , tcdTypeCons = cons } | +tcKindDecl _rec_info KindDecl { tcdLName = L _ kind_name, tcdKVars = | lknames | + , tcdTypeCons = cons } | = do traceTc "tcKindDecl" (ppr kind_name) | | ~(ATyCon kcon) <- tcLookupGlobal kind_name | @@ -1394,7 +1393,9 @@ tcTyConDecl kvars kind TyConDecl { tycon_name = | name, tycon_details = details } | RecCon {} -> panic "tcTyConDecl" "unexpected record | constructor" | let (kcon,_) = splitTyConApp kind | con_kind = mkPiKinds kvars (mkFunTys ks kind) | - return (mkDataKindTyCon kcon (unLoc name) con_kind) | + roles = replicate (length kvars) Nominal | + ++ replicate (length ks) Representational | + return (mkDataKindTyCon kcon (unLoc name) con_kind roles) | | | \end{code} | diff --git a/compiler/types/TyCon.lhs b/compiler/types/TyCon.lhs | index 8ccbcc9..9308713 100644 | --- a/compiler/types/TyCon.lhs | +++ b/compiler/types/TyCon.lhs | @@ -1087,13 +1087,13 @@ mkPromotedDataCon con name unique kind roles | | -- | Construct a type constructor for a type introduced by a 'data | kind' | -- declaration. | -mkDataKindTyCon :: TyCon -> Name -> Kind -> TyCon | -mkDataKindTyCon kc name kind | +mkDataKindTyCon :: TyCon -> Name -> Kind -> [Role] -> TyCon | +mkDataKindTyCon kc name kind roles | = PromotedDataCon { | tyConName = name, | tyConUnique = nameUnique name, | - tyConArity = 0, | - tc_roles = [], -- XXX is this correct? | + tyConArity = length roles, | + tc_roles = roles, | tc_kind = kind, | parentTyCon = kc | } | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

build failures on Linux
by Kazu Yamamoto 13 Sep '13

13 Sep '13

Hi, I cannot build GHC head today on Linux. It seems to me that this bug is relating to the followings: https://github.com/sol/doctest-haskell/issues/59 https://github.com/sol/doctest-haskell/pull/60 Why did the initial value of v_opt_C_ready in GHCI change? --Kazu Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 78% ( 7 / 9) in 'GHC.Types' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /351) in 'GHC.PrimopWrappers' 2% ( 1 / 43) in 'GHC.PrimWrappers' 17% ( 1 / 6) in 'GHC.CString' 31% (170 /540) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: haddock: panic! (the 'impossible' happened) (GHC version 7.7.20130912 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.newSession or GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1

4 4

possible solution! Re: llvm calling convention matters
by Carter Schonwald 13 Sep '13

13 Sep '13

to repeat: I think no one would have object to having a clearly marked, experimental -fllvmExpermentalAVX flag that requires building LLVM with a specified patch, as a way to showcase your multivector work! that would evade all of my objections (provided avx is still exposed with normal -fllvm, but spilled to stack rather than registers), and i'd actually argue in favor of such. Especially since it would not impose any release cycle constraints on a subsequent, systematic exploration for using XMM / YMM / ZMM in the calling convention going forward. @Geoff, Simons, Johan, and others: does anyone object to that approach? applying such a calling convention patch to llvm is really quite straightforward, and the build process is pretty zippy after that too. cheers -Carter On Thu, Sep 12, 2013 at 2:34 AM, Carter Schonwald < carter.schonwald(a)gmail.com> wrote: > that said it does occur to me that there is an alternative solution that > may be acceptable for everyone! > > what about providing a pseudo compatible way called -fllvm-experimentalAVX > (or something), and simply require that for it to be used, the user has an > llvm Patched with the YMM simd in register fun call support? internally > that could just be an llvm way that trips the logic that puts the first few > AVX values in those YMM1-6 slots if they are the first args, so only the > stack spilling logic needs be changed? > > (ie it wouldn't be tied to an llvm version, but rather this pseduo way > flag) > > does that make sense? > > either way, i'd really like having avx even if its always spilled to stack > at funcalls with standard LLVMs! > > cheers > -carter > > > > > On Thu, Sep 12, 2013 at 2:28 AM, Carter Schonwald < > carter.schonwald(a)gmail.com> wrote: > >> Geoff, >> >> a prosaic reason why there *might* be a fundamentally breaking change >> would be the following idea nathan howell suggested to me this afternoon: >> change the Sp and SPLim register so that the X86/x86_64 target can use the >> CPU's Push and (maybe) Pop instructions for the stack manipulations, >> rather than MOV and fam. see http://ghc.haskell.org/trac/ghc/ticket/8272(which is just what i've said). Thats one change thats pretty simple but >> deep, but likely worth exploring. >> >> >> i'm saying any ABI change for GHC 7.10, would likely entail patching LLVM >> 3.4, because thats the only LLVM version likely to come out between now and >> whenever we get 7.10 out (assuming 7.10 lands within the next 8-12 months, >> which is reasonable since we've got noticeably more (amazing) people >> helping out lately). Thus, any change there entails either asking the llvm >> folks to support >1 GHC convention per architecture, or replace the current >> one! I'd rather do the latter than the former, when it comes to asking >> other people to maintain it :) >> (and llvm engineers do in fact help out maintaining that code) >> >> >> have you run a Nofib, or even benchmarks restricted to your multivector >> code, for the current calling convention (including the spilling AVX >> vectors to the stack thats the current plan i gather) VS passing in >> registers with an LLVM built using the patches i worked out ~ 2 months ago? >> it'd be really easy to build that custom llvm, then run the benchmarks! >> (i'm happy to help, and ultimately, benchmarks will reveal if its worth >> while or not! And if the main goal is for your talk, its still valid even >> if its not in the merge window over the next 4 days). >> >> I really think its not obvious what the "best" abi change would be! It >> really will require coming up with a list of variants, implementing them, >> and running nofib with each variant, which i lack the compute/human time >> resources to do this week. Modern hardware is complex enough that for >> something like an ABI change, the only healthy attitude can be "lets >> benchmark it!". >> >> i'd really like any change in calling convention to also improve perf on >> codes that aren't explicitly simd! (and a conservative simd only change, >> blocks/conflicts with that augmentation going forward, and not just for the >> stack pointer example i mention early) >> >> Not just scalar floats in simd registers , but perhaps also words/ints ! >> >> (though that latter bit might be pretty ambitious and subtle, i'll need >> to investigate that a bit to see how feasible it may be). >> SIMD has great support for ints/words, and any partial abi change on the >> llvm backend now would make it hard to support that later well (or at >> least, thats what it looks like to me). actually effectively using simd >> for scalar ints and words should be doable, but might force us to be a bit >> more thoughtful on how GHC internally distinguishes ints used for address >> arithmetic, vs ints used as data. (interestingly, i'm not sure if any >> current extent x86 calling convention does that!) >> >> >> That single change would make 7.10 require a completely different >> llvm and native code gen convention from our current one, plus touch all of >> the code gen on x86 architectures. >> >> >> basically: we're lucky that everyone builds haskell code from source, so >> ABI compat across GHC versions is a non issue. BUT, any ABI changes should >> be backed by benchmarks (at least when the change is performance >> motivated). Likewise, because we use LLVM as an external dep for the -fllvm >> backend, we really need to keep how their release cycle interacts with our >> release cycle, because people use haskell and ghc! which as many like to >> say, is both a boon and a pain ;). >> >> Having people hit ghc acting broken with an llvm that was "supported >> before" is risky support problem to deal with. having an LLVM head variant >> support a modified ABI, and then later needing to break it for 7.10 (for >> one of the possible exploratory reasons above) would lead to a support >> headache I don't wish on anyone. >> >> pardon the verbose answer, but thats my offhand take >> >> cheers >> -Carter >> >> >> On Wed, Sep 11, 2013 at 10:10 PM, Geoffrey Mainland <mainland(a)apeiron.net >> > wrote: >> >>> We support compiling some code with -fllvm and some not in the same >>> executable. Otherwise how could users of the Haskell Platform link their >>> -fllvm-compiled code with native-codegen-compiled libraries like base, >>> etc.? >>> >>> In other words, the LLVM and native back ends use the same calling >>> convention. With my SIMD work, they still use the same calling >>> conventions, but the native codegen can never generate code that uses >>> SIMD instructions. >>> >>> Geoff >>> >>> On 09/11/2013 10:03 PM, Johan Tibell wrote: >>> > OK. But that doesn't create a problem for the code we output with the >>> > LLVM backend, no? Or do we support compiling some code with -fllvm and >>> > some not in the same executable? >>> > >>> > >>> > On Wed, Sep 11, 2013 at 6:56 PM, Geoffrey Mainland >>> > <mainland(a)apeiron.net <mailto:mainland@apeiron.net>> wrote: >>> > >>> > We definitely have interop between the native codegen and the LLVM >>> > back >>> > end now. Otherwise anyone who wanted to use the LLVM back end >>> > would have >>> > to build GHC themselves. Interop means that users can install the >>> > Haskell Platform and still use -fllvm when it makes a performance >>> > difference. >>> > >>> > Geoff >>> > >>> > On 09/11/2013 07:59 PM, Johan Tibell wrote: >>> > > Do nothing different than you're doing for 7.8, we can sort it >>> out >>> > > later. Just put a comment on the primops saying they're >>> > LLVM-only. See >>> > > e.g. >>> > > >>> > > >>> > > >>> > >>> https://github.com/ghc/ghc/blob/master/compiler/prelude/primops.txt.pp#L181 >>> > > >>> > > for an example how to add docs to primops. >>> > > >>> > > I don't think we need interop between the native and the LLVM >>> > > backends. We don't have that now do we (i.e. they use different >>> > > calling conventions). >>> > > >>> > > >>> > > >>> > > On Wed, Sep 11, 2013 at 4:51 PM, Geoffrey Mainland >>> > > <mainland(a)apeiron.net <mailto:mainland@apeiron.net> >>> > <mailto:mainland@apeiron.net <mailto:mainland@apeiron.net>>> >>> wrote: >>> > > >>> > > On 09/11/2013 07:44 PM, Johan Tibell wrote: >>> > > > On Wed, Sep 11, 2013 at 4:40 PM, Geoffrey Mainland >>> > > <mainland(a)apeiron.net <mailto:mainland@apeiron.net> >>> > <mailto:mainland@apeiron.net <mailto:mainland@apeiron.net>>> >>> wrote: >>> > > > > Do you mean we need a reasonable emulation of the SIMD >>> > primops for >>> > > > > the native codegen? >>> > > > >>> > > > Yes. Reasonable in the sense that it computes the right >>> > result. >>> > > I can >>> > > > see that some code might still want to #ifdef (if the >>> > fallback isn't >>> > > > fast enough). >>> > > >>> > > Two implications of this requirement: >>> > > >>> > > 1) There will not be SIMD in 7.8. I just don't have the >>> > time. In fact, >>> > > what SIMD support is there already will have to be removed >>> if we >>> > > cannot >>> > > live with LLVM-only SIMD primops. >>> > > >>> > > 2) If we also require interop between the LLVM back-end and >>> > the native >>> > > codegen, then we cannot pass any SIMD vectors in >>> > registers---they all >>> > > must be passed on the stack. >>> > > >>> > > My plan, as discussed with Simon PJ, is to not support SIMD >>> > primops at >>> > > all with the native codegen. If there is a strong feeling >>> that >>> > > this *is >>> > > not* the way to go, the I need to know ASAP. >>> > > >>> > > Geoff >>> > > >>> > > >>> > > >>> > >>> > >>> >>> >> >

2 7

AMP patch and performance tests failures
by Jan Stolarek 12 Sep '13

12 Sep '13

I am getting validation failures from T3064 performance test: =====> T3064(normal) 1741 of 3782 [0, 0, 0] cd ./perf/compiler && '/5playpen/t-jastol/ghc-validate/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 30 +/-20% Lower bound peak_megabytes_allocated: 24 Upper bound peak_megabytes_allocated: 36 Actual peak_megabytes_allocated: 39 This tests has some instances of Monads and Applicatives so my random guess is that AMP patch caused that. Can anyone working on that patch confirm or deny that it increases allocation and causes this failure? I also got a validation failure from T5837 a couple of times, but it doesn't happen always. Janek

3 2

running out of bits in lexer
by Richard Eisenberg 12 Sep '13

12 Sep '13

Hi devs, I'm in the process of reimplementing role annotations (#8185). I need to add a new pseudo-keyword 'role' to the lexer, and I'm initially tempted to guard the lexing of this keyword with an extension bit (like, say, tyFamBit in Lexer.x). But, there are already bits 0 to 31 taken, and the type of the bitmap is Int, so I'm out of luck. However, I think there's a way out: the parser should do the right thing when it sees these pseudo-keywords, and hopefully the downstream code could check the enabled options. So, it would seem that having some of these bit controls in the lexer is unnecessary -- more a belt-and-suspenders thing than anything else. So, I propose to let the lexer treat 'role' specially in all cases, relying on the parser to treat it like an ordinary varid except when 'role' comes right after 'type'. Is there something I'm missing here? In particular, I can't think of a good reason not to treat the pseudo-keyword 'family' in the same way and allow it to lex regardless of the extensions. This might also improve error messages. Thanks, Richard

2 1

delete remote branch
by Nicolas Frisby 12 Sep '13

12 Sep '13

I just merged in my -fdicts-strict work, so I was deleting the old branch… but it's rejected for some reason. $ git push origin --delete dicts-strict remote: performing tab-check... remote: + refs/heads/dicts-strict ghc <my-username> DENIED by fallthru remote: error: hook declined to update refs/heads/dicts-strict To ssh://git@git.haskell.org/ghc.git ! [remote rejected] dicts-strict (hook declined) error: failed to push some refs to 'ssh://git@git.haskell.org/ghc.git' Git gurus chime in? Thanks.

6 10

Profiling segfaulting in HEAD again
by Edward Z. Yang 12 Sep '13

12 Sep '13

Hey folks, I noticed that profiling has started segfaulting again in HEAD. Anyone recently push something that might be triggering this? Edward

2 2

管理者如何才能走出管理的困惑
by 樊泽邦 11 Sep '13

11 Sep '13

1 0

RE: [core libraries] RE: Alex and new Bool primops
by Simon Peyton-Jones 11 Sep '13

11 Sep '13

(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(a)gmail.com [mailto:michael.snoyman@gmail.com] On Behalf Of Michael Snoyman Sent: 10 September 2013 05:28 To: Simon Peyton-Jones Cc: core-libraries-committee(a)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(a)microsoft.com<mailto:simonpj@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@haskell.org<mailto:ghc-devs-bounces@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(a)apeiron.net<mailto:mainland@apeiron.net>> | > Do: "Jan Stolarek" <jan.stolarek(a)p.lodz.pl<mailto:jan.stolarek@p.lodz.pl>> | > DW: "ghc-devs" <ghc-devs(a)haskell.org<mailto: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(a)haskell.org<mailto:ghc-devs@haskell.org> | >> http://www.haskell.org/mailman/listinfo/ghc-devs | > | | | _______________________________________________ | ghc-devs mailing list | ghc-devs(a)haskell.org<mailto:ghc-devs@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(a)googlegroups.com<mailto:haskell-core-libraries%2Bunsubscribe@googlegroups.com>. For more options, visit https://groups.google.com/groups/opt_out.

5 4