- ghc-devs - Haskell.org

Haddock strings in .hi files
by Mateusz Kowalczyk 21 Mar '14

21 Mar '14

Hi all, I saw https://ghc.haskell.org/trac/ghc/ticket/5467 pop up in my inbox and it reminded me of something I've been wondering for a while: why do we not store Haddock docstrings in the interface file? I think that if we did, we could do some great things: 1. Show docs in GHCi (I vaguely recall someone working on this ~1 year ago, does anyone have any info?) 2. Allow Haddock to work a lot faster: the big majority of time spent when creating documentation is actually spent by Haddock calling various GHC functions, such as type-checking the modules. Only a small amount of time is actually spent by Haddock on other tasks such as parsing or outputting the documentation. If we could simply get everything we need from the .hi files, we save ourselves a lot of time. 3. Allow Haddock to create partial documentation: a complaint I sometimes hear is if anything at all in the project doesn't type check, we don't get any documentation at all. I think that it'd be viable to generate only the documentation for the modules/functions that do type-check and perhaps skip type signatures for everything else. Points 1. and 2. are of clear benefit. Point 3. is a simple afterthought and thinking about it some more, I think that maybe it'd be possible to do this with what we have right now: is type-checking separate parts of the module supported? Can we retrieve documentation for the parts that don't type-check? I am asking for input on what people think. I am not familiar at all with what goes into the .hi file (and I can't find anything concrete! Am I missing some wiki page?) at all and why. At the very least, 1. should be easy to implement. It was suggested that I submit a proposal for this as part of GSoC, namely implementing 1. and 2.. I admit that having much faster documentation builds would be amazing and Edward K. and Carter S. seem to think that this is very do-able in the 3 month period that GSoC runs over. While I say all this, I have already submitted my proposal on a different topic. I am considering writing this up and submitting this as well but I am looking for some insight into the problem first. If there are any students around still looking for ideas, please do speak up if you want to snatch this. If there are people that are eager to mentor something like this then I suppose they should speak up too. Thanks! -- Mateusz K.

6 12

Possible refactoring for __stg_gc_fun in HeapStackCheck.cmm
by Horsng Junn 20 Mar '14

20 Mar '14

Hi list! This is my first mail to the list; please correct me if I made any mistakes. I’ve been studying GHC source code for studying’s sake, and think I’ve found a few problems in this function. Below comes the function in its current form: ———————————————————— __stg_gc_fun /* explicit stack */ { W_ size; W_ info; W_ type; info = %GET_FUN_INFO(UNTAG(R1)); // cache the size type = TO_W_(StgFunInfoExtra_fun_type(info)); if (type == ARG_GEN) { size = BITMAP_SIZE(StgFunInfoExtra_bitmap(info)); } else { if (type == ARG_GEN_BIG) { #ifdef TABLES_NEXT_TO_CODE // bitmap field holds an offset size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) + %GET_ENTRY(UNTAG(R1)) /* ### */ ); #else size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) ); #endif } else { size = BITMAP_SIZE(W_[stg_arg_bitmaps + WDS(type)]); } } #ifdef NO_ARG_REGS // we don't have to save any registers away Sp_adj(-3); Sp(2) = R1; Sp(1) = size; Sp(0) = stg_gc_fun_info; jump stg_gc_noregs []; #else W_ type; type = TO_W_(StgFunInfoExtra_fun_type(info)); // cache the size if (type == ARG_GEN || type == ARG_GEN_BIG) { // regs already saved by the heap check code Sp_adj(-3); Sp(2) = R1; Sp(1) = size; Sp(0) = stg_gc_fun_info; // DEBUG_ONLY(foreign "C" debugBelch("stg_fun_gc_gen(ARG_GEN)");); jump stg_gc_noregs []; } else { jump W_[stg_stack_save_entries + WDS(type)] [*]; // all regs live // jumps to stg_gc_noregs after saving stuff } #endif /* !NO_ARG_REGS */ } The problems I see: 1. “type” variable is declared and its value calculated twice, 2. if (type == ARG_GEN … check is needlessly done twice, 3. “size" value is calculated and then discarded in !NO_ARG_REGS, for types other than ARG_GEN or ARG_GEN_BIG, and 4. (this is a minor one) Sp_adj(-3) ~ jmup_stg_gc_noregs code is duplicated. I know they’re in separate #if branch but still... And my proposed fixes are: ———————————————————— __stg_gc_fun /* explicit stack */ { W_ size; W_ info; W_ type; info = %GET_FUN_INFO(UNTAG(R1)); // cache the size type = TO_W_(StgFunInfoExtra_fun_type(info)); if (type == ARG_GEN) { // regs already saved by the heap check code size = BITMAP_SIZE(StgFunInfoExtra_bitmap(info)); } else { if (type == ARG_GEN_BIG) { // regs already saved by the heap check code #ifdef TABLES_NEXT_TO_CODE // bitmap field holds an offset size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) + %GET_ENTRY(UNTAG(R1)) /* ### */ ); #else size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) ); #endif } else { #ifdef NO_ARG_REGS // we don't have to save any registers away size = BITMAP_SIZE(W_[stg_arg_bitmaps + WDS(type)]); #else jump W_[stg_stack_save_entries + WDS(type)] [*]; // all regs live // jumps to stg_gc_noregs after saving stuff #endif } } Sp_adj(-3); Sp(2) = R1; Sp(1) = size; Sp(0) = stg_gc_fun_info; jump stg_gc_noregs []; } What do you guys think? Thanks, Horsng Junn

2 2

Pretty printing
by Simon Peyton Jones 19 Mar '14

19 Mar '14

Gergo I'm a bit out of date... did you update those test results etc to get to clean validate? S

3 2

"quick" vs "perf" builds
by Johan Tibell 19 Mar '14

19 Mar '14

Hi, In my mind the "quick" build should be like the "perf" build, except building the stage2 compiler should be much faster. However, the perf build uses GhcLibHcOpts = -O2 while the quick build uses GhcLibHcOpts = -O -fasm This means that if you're working on optimizing the generated code and are running benchmarks to verify your results, the quick build doesn't do the right thing. Since the purpose of the quick build is to work on the stage2 compiler, would it make sense having it build the libraries in the same way as the perf build? -- Johan

4 5

Re: We need to add role annotations for 7.8
by David Terei 19 Mar '14

19 Mar '14

Adding in GHC-DEV. Yes, sorry for no contact, my GHC email filter was misconfigured so only got alerted when SPJ emailed me directly a few days back. On 18 March 2014 17:36, David Mazieres expires 2014-06-16 PDT <mazieres-i58umkudjfnfpfdx6jbbn3ymzi(a)temporary-address.scs.stanford.edu> wrote: > At Fri, 14 Mar 2014 18:45:16 +0100, > Mikhail Glushenkov wrote: >> >> Hi Richard, >> >> > The real trouble with making this decision is that we have no real >> > guidance. We've tried contacting David Terei (the originator of >> > Safe Haskell) several times to no avail. If you are an actual >> > consumer of Safe Haskell and would like to share your opinion on >> > this front, I do encourage you to make a ticket, essentially >> > requesting a resurrection of the extra Safe checks. >> >> Yes, it would be nice if David Terei or David Mazières (CC:ed) could comment. > > Sadly, it appears some mail may not have made it through to David > Terei's mailbox. > > At any rate, David and I just discussed the new Coerce typeclass. > Based on David's understanding of its behavior, it sounds pretty > dangerous for Safe Haskell. At a minimum, the programmer is going to > need to understand a lot more than Haskell 2010 to write secure code. > > Based on my possibly limited understanding of the new > feature--automatically generating instances of the Coerce type seems > very un-Haskell-like. By analogy, we could automatically generate > instance of Read and Show (or add equivalent DebugRead/DebugShow > classes) wherever possible, but this would similarly break abstraction > by providing effective access to non-exported constructors. > > I understand why there is a need for something better than > GeneralizedNewtypeDeriving. However, implementing Coerce as a > typeclass has the very serious disadvantage that there is no Haskell > mechanism for controlling instance exports. And if we are going to > add a new mechanism (roles) to control such exports, exporting an > instance that is never requested and that undermines modularity and > abstraction is an unfortunate default. > > It may be too late for this, but a cleaner solution more in keeping > with other extensions would be to have a -XDeriveCoerce extension that > allows Coerce to be explicitly derived when safe. This could be > combined with leaving the previous behavior of > GeneralizedNewtypeDeriving and just deprecating the language feature. > > Though controlling instance exports does not have a precedent, another > option might be to special-case the Coerce class and only export > instances of Coerce when all constructors of a type are also exported. > This would prevent anyone from using Coerce to do things they couldn't > already do manually. > > David >

1 0

Re: [commit: ghc] ghc-parmake-gsoc: Implement the parallel upsweep (#910) (8d9edfe)
by Johan Tibell 17 Mar '14

17 Mar '14

I just had reason to have a look at this code. I just want to say thanks for writing such nice, readable code. I wish all code in GHC had nicely written Haddock like these. Would make GHC hacking a bit more approachable. On Tue, Aug 27, 2013 at 4:11 PM, <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : ghc-parmake-gsoc > Link : > http://ghc.haskell.org/trac/ghc/changeset/8d9edfed74e8fd03933d4e3540f6372c2… > > >--------------------------------------------------------------- > > commit 8d9edfed74e8fd03933d4e3540f6372c269de538 > Author: Patrick Palka <patrick(a)parcs.ath.cx> > Date: Wed Aug 21 16:55:52 2013 -0400 > > Implement the parallel upsweep (#910) > > The parallel upsweep is the parallel counterpart to the default > sequential upsweep. It attempts to compile modules in parallel by > subdividing the work of the upsweep into parts that can be executed > concurrently by multiple Haskell threads. > > In order to enable the parallel upsweep, the user has to pass the -jN > flag to GHC, where N is an optional number denoting the number of jobs, > or modules, to compile in parallel, like with GNU make. In GHC this > just > sets the number of capabilities to N. > > > >--------------------------------------------------------------- > > 8d9edfed74e8fd03933d4e3540f6372c269de538 > compiler/main/DynFlags.hs | 8 + > compiler/main/GhcMake.hs | 354 > ++++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 359 insertions(+), 3 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder > --ignore-space-at-eol --cc 8d9edfed74e8fd03933d4e3540f6372c269de538 > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

-ddump-types vs -fprint-explicit-foralls, and symbol-ness of worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a) (fwd)]
by Dr. ERDI Gergo 17 Mar '14

17 Mar '14

I've just realized the original subject of this mail probably didn't properly highlight that this unearthed two issues that I'd like to hear opinions on, before going on to fix them. So here's my original mail: ---------- Forwarded message ---------- Date: Sun, 16 Mar 2014 00:50:19 +0800 (SGT) From: Dr. ERDI Gergo <gergo(a)erdi.hu> To: Joachim Breitner <mail(a)joachim-breitner.de> Cc: GHC Devs <ghc-devs(a)haskell.org> Subject: Re: [commit: ghc] master: Pretty-print the following TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a) On Sat, 15 Mar 2014, Joachim Breitner wrote: > > Unexpected failures: > indexed-types/should_compile T3017 [stderr mismatch] (normal) > roles/should_compile Roles1 [stderr mismatch] (normal) > roles/should_compile Roles2 [stderr mismatch] (normal) > simplCore/should_compile T4306 [bad exit code] (normal) > th T8884 [stderr mismatch] (normal) > typecheck/should_compile tc231 [stderr mismatch] (normal) > https://s3.amazonaws.com/archive.travis-ci.org/jobs/20819762/log.txt > Are these related to your changes, and are pending fixing? (If not it > might take too long until we notice, and it will be more difficult to > find the cause.) Hi, Yes, these are related. However, they all point to just a change in the output format of -ddump-types so that by default, foralls are not printed. The old output format can be restored by passing in an extra -fprint-explicit-foralls flag. I think this is actually an improvement, and thus my suggestion is to simply update the expected output of these tests. The one interesting case is T4306 which fails because the generated name $wupd is regarded as an infix name, and thus with my new code is rendered as ($wupd) :: GHC.Prim.Double# -> GHC.Prim.Double# instead of the old $wupd :: GHC.Prim.Double# -> GHC.Prim.Double# I think this is actually a bug in isSymOcc, since I don't think the intention behind the generated name $wupd is to be regarded as an infix name. So we could change isLexVarSym so that if the first character is $, the rest is still checked for symbol-ness. If there's agreement on this, I'm happy to implement both changes. Bye, Gergo

4 5

Re: [commit: ghc] master: Pretty-print the following TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a)
by Johan Tibell 15 Mar '14

15 Mar '14

Could these changes be related to the validate failures I just posted about on the mailing list? On Thu, Mar 13, 2014 at 2:21 PM, <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/065c35a9d6d48060c8fac8d755833349c… > > >--------------------------------------------------------------- > > commit 065c35a9d6d48060c8fac8d755833349ce58b35b > Author: Dr. ERDI Gergo <gergo(a)erdi.hu> > Date: Thu Mar 13 21:18:39 2014 +0800 > > Pretty-print the following TyThings via their IfaceDecl counterpart: > * AnId > * ACoAxiom > * AConLike > > > >--------------------------------------------------------------- > > 065c35a9d6d48060c8fac8d755833349ce58b35b > compiler/iface/IfaceSyn.lhs | 2 +- > compiler/iface/MkIface.lhs | 10 +++++++- > compiler/main/PprTyThing.hs | 59 > ++++++++++--------------------------------- > 3 files changed, 23 insertions(+), 48 deletions(-) > > diff --git a/compiler/iface/IfaceSyn.lhs b/compiler/iface/IfaceSyn.lhs > index 8ca8582..7484b37 100644 > --- a/compiler/iface/IfaceSyn.lhs > +++ b/compiler/iface/IfaceSyn.lhs > @@ -1100,7 +1100,7 @@ pprIfaceDecl (IfaceClass {ifCtxt = context, ifName = > clas, ifTyVars = tyvars, > sep (map ppr sigs)]) > > pprIfaceDecl (IfaceAxiom {ifName = name, ifTyCon = tycon, ifAxBranches = > branches }) > - = hang (ptext (sLit "axiom") <+> ppr name <> colon) > + = hang (ptext (sLit "axiom") <+> ppr name <> dcolon) > 2 (vcat $ map (pprAxBranch $ Just tycon) branches) > > pprIfaceDecl (IfacePatSyn { ifName = name, ifPatHasWrapper = has_wrap, > diff --git a/compiler/iface/MkIface.lhs b/compiler/iface/MkIface.lhs > index 0af9af6..51df08c 100644 > --- a/compiler/iface/MkIface.lhs > +++ b/compiler/iface/MkIface.lhs > @@ -1461,7 +1461,7 @@ tyThingToIfaceDecl (AnId id) = idToIfaceDecl id > tyThingToIfaceDecl (ATyCon tycon) = tyConToIfaceDecl emptyTidyEnv tycon > tyThingToIfaceDecl (ACoAxiom ax) = coAxiomToIfaceDecl ax > tyThingToIfaceDecl (AConLike cl) = case cl of > - RealDataCon dc -> pprPanic "toIfaceDecl" (ppr dc) -- Should be > trimmed out earlier > + RealDataCon dc -> dataConToIfaceDecl dc -- for ppr purposes only > PatSynCon ps -> patSynToIfaceDecl ps > > -------------------------- > @@ -1477,6 +1477,14 @@ idToIfaceDecl id > ifIdInfo = toIfaceIdInfo (idInfo id) } > > -------------------------- > +dataConToIfaceDecl :: DataCon -> IfaceDecl > +dataConToIfaceDecl dataCon > + = IfaceId { ifName = getOccName dataCon, > + ifType = toIfaceType (dataConUserType dataCon), > + ifIdDetails = IfVanillaId, > + ifIdInfo = NoInfo } > + > +-------------------------- > patSynToIfaceDecl :: PatSyn -> IfaceDecl > patSynToIfaceDecl ps > = IfacePatSyn { ifName = getOccName . getName $ ps > diff --git a/compiler/main/PprTyThing.hs b/compiler/main/PprTyThing.hs > index 27e7390..fb92b5a 100644 > --- a/compiler/main/PprTyThing.hs > +++ b/compiler/main/PprTyThing.hs > @@ -23,20 +23,18 @@ module PprTyThing ( > ) where > > import TypeRep ( TyThing(..) ) > -import ConLike > import DataCon > -import PatSyn > import Id > import TyCon > import Class > -import Coercion( pprCoAxiom, pprCoAxBranch ) > +import Coercion( pprCoAxBranch ) > import CoAxiom( CoAxiom(..), brListMap ) > import HscTypes( tyThingParent_maybe ) > -import HsBinds( pprPatSynSig ) > import Type( tidyTopType, tidyOpenType, splitForAllTys, funResultTy ) > import Kind( synTyConResKind ) > import TypeRep( pprTvBndrs, pprForAll, suppressKinds ) > import TysPrim( alphaTyVars ) > +import MkIface ( tyThingToIfaceDecl ) > import TcType > import Name > import VarEnv( emptyTidyEnv ) > @@ -44,7 +42,6 @@ import StaticFlags( opt_PprStyle_Debug ) > import DynFlags > import Outputable > import FastString > -import Data.Maybe > > -- > ----------------------------------------------------------------------------- > -- Pretty-printing entities that we get from the GHC API > @@ -76,7 +73,7 @@ pprTyThingLoc tyThing > > -- | Pretty-prints a 'TyThing'. > pprTyThing :: TyThing -> SDoc > -pprTyThing thing = ppr_ty_thing showAll thing > +pprTyThing thing = ppr_ty_thing (Just showAll) thing > > -- | Pretty-prints a 'TyThing' in context: that is, if the entity > -- is a data constructor, record selector, or class method, then > @@ -88,7 +85,7 @@ pprTyThingInContext thing > where > go ss thing = case tyThingParent_maybe thing of > Just parent -> go (getName thing : ss) parent > - Nothing -> ppr_ty_thing ss thing > + Nothing -> ppr_ty_thing (Just ss) thing > > -- | Like 'pprTyThingInContext', but adds the defining location. > pprTyThingInContextLoc :: TyThing -> SDoc > @@ -100,21 +97,17 @@ pprTyThingInContextLoc tyThing > -- the function is equivalent to 'pprTyThing' but for type constructors > -- and classes it prints only the header part of the declaration. > pprTyThingHdr :: TyThing -> SDoc > -pprTyThingHdr (AnId id) = pprId id > -pprTyThingHdr (AConLike conLike) = case conLike of > - RealDataCon dataCon -> pprDataConSig dataCon > - PatSynCon patSyn -> pprPatSyn patSyn > -pprTyThingHdr (ATyCon tyCon) = pprTyConHdr tyCon > -pprTyThingHdr (ACoAxiom ax) = pprCoAxiom ax > +pprTyThingHdr = ppr_ty_thing Nothing > > ------------------------ > -ppr_ty_thing :: ShowSub -> TyThing -> SDoc > -ppr_ty_thing _ (AnId id) = pprId id > -ppr_ty_thing _ (AConLike conLike) = case conLike of > - RealDataCon dataCon -> pprDataConSig dataCon > - PatSynCon patSyn -> pprPatSyn patSyn > -ppr_ty_thing ss (ATyCon tyCon) = pprTyCon ss tyCon > -ppr_ty_thing _ (ACoAxiom ax) = pprCoAxiom ax > +-- NOTE: We pretty-print 'TyThing' via 'IfaceDecl' so that we can reuse > the > +-- 'TyCon' tidying happening in 'tyThingToIfaceDecl'. See #8776 for > details. > +ppr_ty_thing :: Maybe ShowSub -> TyThing -> SDoc > +ppr_ty_thing mss tyThing = case tyThing of > + ATyCon tyCon -> case mss of > + Nothing -> pprTyConHdr tyCon > + Just ss -> pprTyCon ss tyCon > + _ -> ppr $ tyThingToIfaceDecl tyThing > > pprTyConHdr :: TyCon -> SDoc > pprTyConHdr tyCon > @@ -143,10 +136,6 @@ pprTyConHdr tyCon > | isAlgTyCon tyCon = pprThetaArrowTy (tyConStupidTheta tyCon) > | otherwise = empty -- Returns 'empty' if null theta > > -pprDataConSig :: DataCon -> SDoc > -pprDataConSig dataCon > - = ppr_bndr dataCon <+> dcolon <+> pprTypeForUser (dataConUserType > dataCon) > - > pprClassHdr :: Class -> SDoc > pprClassHdr cls > = sdocWithDynFlags $ \dflags -> > @@ -158,28 +147,6 @@ pprClassHdr cls > where > (tvs, funDeps) = classTvsFds cls > > -pprId :: Var -> SDoc > -pprId ident > - = hang (ppr_bndr ident <+> dcolon) > - 2 (pprTypeForUser (idType ident)) > - > -pprPatSyn :: PatSyn -> SDoc > -pprPatSyn patSyn > - = pprPatSynSig ident is_bidir args (pprTypeForUser rhs_ty) prov req > - where > - ident = patSynId patSyn > - is_bidir = isJust $ patSynWrapper patSyn > - > - args = fmap pprParendType (patSynTyDetails patSyn) > - prov = pprThetaOpt prov_theta > - req = pprThetaOpt req_theta > - > - pprThetaOpt [] = Nothing > - pprThetaOpt theta = Just $ pprTheta theta > - > - (_univ_tvs, _ex_tvs, (prov_theta, req_theta)) = patSynSig patSyn > - rhs_ty = patSynType patSyn > - > pprTypeForUser :: Type -> SDoc > -- We do two things here. > -- a) We tidy the type, regardless > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

4 3

Arrow notation vs RebindableSyntax
by Nicolas Frisby 15 Mar '14

15 Mar '14

The 7.8-rc2 User Guide for rebindable syntax includes: Arrow notation (see Section 7.16, "Arrow notation ") uses whatever arr, > (>>>), first, app, (|||) and loop functions are in scope. But unlike the > other constructs, the types of these functions must match the Prelude types > very closely. Details are in flux; if you want to use this, ask! I want to use this: my types for the functions apparently do not match the Prelude types closely enough. Whom should I ask about this? Thanks very much. -Nick ----- Further Context If I do something similar with Monad and RebindableSyntax, it type-checks. I'm doing some experimentation for work. I'd like to index my arrows as follows. (Disclaimer: I have not yet considered any of the laws; I do not currently intend to support `app' and |||.) infixr 1 >>>, <<< type family (:*:) (i :: Maybe *) (j :: Maybe *) :: Maybe * type instance Nothing :*: j = j type instance i :*: Nothing = i type instance Just i :*: Just j = Just (i,j) returnA :: IArrow arr => arr Nothing a a returnA = arr id -- second, ***, and &&& can have the standard default definitions class IArrow (arr :: Maybe * -> * -> * -> *) where arr :: (b -> c) -> arr Nothing b c (>>>) :: arr i a b -> arr j b c -> arr (i :*: j) a c first :: arr i b c -> arr i (b,d) (c,d) Unfortunately, the following does not type-check with -XArrows and -XRebindableSyntax. diagram :: IArrow arr => arr f x fx -> arr g x gx -> arr (f :*: g) x gx diagram f g = proc x -> do fx <- f -< x gx <- g -< x returnA -< gx The error messages indicate that the type-checker is attempting to unify the types of f, g, returnA, and the entire proc block. However, the copy-and-pasted desugaring of that code *does* type-check (mutatis mutandi). This S data type is an example of an IArrow. data S i a b where SN :: ( a -> b ) -> S Nothing a b SJ :: s -> ((a,s) -> (b,s)) -> S (Just s) a b In terms of the S type, the objective of IArrow is to allow each "box in the diagram" to have its own state.

2 1

testing ghc-7.8 rc2: linker issues
by Matthias Fischmann 14 Mar '14

14 Mar '14

hi, this time i am running 7.8 rc2 (binary for x64 on debian testing). after a successful '/usr/bin/cabal install cabal-install', i am running into different instances of this: | [...] | [25 of 25] Compiling Text.ParserCombinators.Parsec.Perm ( Text/ParserCombinators/Parsec/Perm.hs, dist/build/Text/ParserCombinators/Parsec/Perm.o ) | /usr/bin/ld: cannot find -lHSmtl-2.1.2-ghc7.8.0.20140228 | collect2: error: ld returned 1 exit status | Failed to install parsec-3.1.5 | cabal: Error: some packages failed to install: | network-2.4.2.2 depends on parsec-3.1.5 which failed to install. | parsec-3.1.5 failed during the building phase. The exception was: | ExitFailure 1 what makes me suspect this could be relevant to this list is that the symptoms are weirdly sporadic. my story: 1. cabal install string-conversions fails because -lHStext-1.1.0.1 cannot be found. 2. ghc-pkg unregister <a few packages> 3. cabal install network (which pulls text) => fails (see above) 4. cabal install string-conversions => works! i will read up on dynamic linking in ghc now. cheers, matthias

2 1