February 2014 - ghc-devs

workaround to get both domain-specific errors and also multi-modal type inference?
by Nicolas Frisby 19 Feb '14

19 Feb '14

Hi all. I have a question for those savvy to the type-checker's internal workings. For uses of the following function, can anyone suggest a means of forcing GHC to attempt to solve C a b even if a~b fails? > dslAsTypeOf :: (C a b,a~b) => a -> b -> a > dslAsTypeOf x _ = x > > class C a b -- no methods Just for concreteness, the following are indicative of the variety of instances that I expect C to have. (I don't think this actually affects the question above.) > instance C DSLType1 DSLType1 > instance C DSLType2 DSLType2 > instance C x y => C (DSLType3 x) (DSLType3 y) > > instance IndicativeErrorMessage1 => C DSLType1 DSLType2 > instance IndicativeErrorMessage2 => C DSLType2 (DSLType3 y) > > class IndicativeErrorMessage1 -- will never have instances > class IndicativeErrorMessage2 -- will never have instances Thank you for your time. =================================== Keep reading for the "short story", the "long story", and two ideas for a small GHC patch that would enable my technique outlined above. ===== short story ===== The motivation of dslAsTypeOf is to provide improved error messages when a and b are not equal. Unfortunately, the user will never see IndicativeErrorMessage. It appears that GHC does not attempt to solve C a b if a~b fails. That's understandable, since the solution of C a b almost certainly depends on the "value" of its arguments... Hence, the question at the top of this email. ===== long story ===== A lot of the modern type-level programming capabilities can be put to great use in creating type systems for embedded domain specific languages. These type systems can enforce some impressive properties. However, the error messages you get when one of those property is not satisfied can be pretty abysmal. In my particular case, I have a phantom type where the tag carries all the domain-specific information. > newtype U (tag :: [Info]) a = U a and I have an binary operation that requires the tag to be equivalent for all three types. > plus :: Num a => U tag a -> U tag a -> U tag a > plus (U x) (U y) = U $ x + y This effectively enforces the property I want for U values. Unfortunately, the error messages can seem dimwitted. > ill_typed = plus (U 1 :: U [Foo,Bar,Baz] Int) (U 2 :: U [Foo,Baz] Int) The `ill_typed` value gives an error message (in GHC 7.8) saying Bar : Baz : [] is not equal to Baz : [] (It's worse in GHC 7.4. I don't have access to a 7.6 at the moment.) I'd much rather have it say that "Bar is missing from the first summand's list." And I can define a class that effectively conveys that information in a "domain-specific error message" which is actually a "no instance of <IndicativeClassName> tag1 tag2" message. > friendlier_plus :: (FriendlyEqCheck tag1 tag2 tag3,Num a) => U tag1 a -> U tag2 a -> U tag3 a The `friendlier_plus' function gives useful error messages if tag1, tag2, and tag3 are all fully monomorphic. However, it does not support inference: > zero :: Num a => U tag a > zero = U 0 > > x = U 4 :: U [Foo,Baz] Int > > -- both of these are ill-typed :( > should_work1 = (friendlier_plus zero x) `asTypeOf` x -- tag1 is unconstrained > should_work2 = friendlier_plus x x -- tag3 is unconstrained Neither of those terms type-check, since FriendlyEqCheck can't determine if the unconstrained `tag' variable is equal to the other tags. So, can we get the best of both worlds? > best_plus :: > ( FriendlyEqCheck tag1 tag2 tag3 , tag1 ~ tag2, tag2 ~ tag3, Num a) => U tag1 a -> U tag2 a -> U tag3 a No, unfortunately not. Now the `should_work*' functions type-check, but an ill-typed use of `best_plus' gives the same poor error message that `plus' would give. Hence, the question at the top of this email. ===== two ideas ===== If my question at the top of this email cannot be answered in the affirmative, perhaps a small patch to GHC would make this sort of approach a viable lightweight workaround for improving domain-specific error messages. (I cannot estimate how difficult this would be to implement in the type-checker.) Two alternative ideas. 1) An "ALWAYS_ATTEMPT" PRAGMA that you can place on the class C so that it is attempted even if a related ~ constraint fails. 2) An OrElse constraint former, offering *very* constrained back-tracking. > possibleAsTypeOf :: ((a ~ b) `OrElse` C a b) => a -> b -> a > possibleAsTypeOf x _ = x Requirements: C must have no superclasses, no methods, and no fundeps. Specification: If (a~b) fails and (C a b) is satisfiable, then the original inequality error message would be shown to the user. Else, C's error message is used. =================================== You made it to the bottom of the email! Thanks again.

5 12

Idea for improving communication between devs and potential devs
by Howard B. Golden 19 Feb '14

19 Feb '14

Hi, I'd like to get involved in developing, but I recognize the learning curve involved. To get started I'd like to improve the Trac wiki documentation. Part of this would include additional documentation of less-documented parts of the compiler and RTS. In addition, I'd like to start some sort of "what's new" that boils down the GHC Dev mailing list discussion as LWN does for the Linux kernel mailing list. I don't imagine that I can do this all by myself, but I hope this idea would resonate with others looking to get started as well. This is meant to be more frequent and more detailed than what HCAR does for GHC now, though I don't expect anyone can do it weekly. Please let me know what you think about this idea. I'm open to any suggestions for improving it also. Howard B. Golden Northridge, CA, USA

6 7

Build failure of 7.8RC1 on OSX Mountain Lion
by Edsko de Vries 18 Feb '14

18 Feb '14

Possibly I did something wrong (certainly when I tried to build something very close to RC1 at Austin's request it worked fine), but now I am getting In file included from rts/sm/Evac.c:21:0: rts/sm/GCTDecl.h:71:0: error: thread-local storage not supported for this target (Host compiler: ghc 7.6.3, no mk/build.mk, standard ./configure --prefix=.., make) Any ideas? -Edsko

2 1

patch for eventlog tracing in forkProcess
by Duncan Coutts 18 Feb '14

18 Feb '14

Hi folks, This is a bit of code I've had lying around for ages but that I never properly tested or applied. This snippet is in danger of getting lost so I'm sending it in and perhaps someone can try it. There's this TODO in rts/Schedule.c forkProcess(): // TODO: need to trace various other things in the child // like startup event, capabilities, process info etc The context is that the RTS is doing a fork() and we have the eventlog turned on. The child process makes is own new eventlog file. So events we do during the startup of the RTS need to be duplicated here. // Trace various things in the child like startup event, capabilities, // process info etc. This is all so that the eventlog for the new // child process will have same stuff as if it were started standalone. traceEventStartup(); traceCapsetCreate(CAPSET_OSPROCESS_DEFAULT, CapsetTypeOsProcess); traceCapsetCreate(CAPSET_CLOCKDOMAIN_DEFAULT, CapsetTypeClockdomain); for (i=0; i < n_capabilities; i++) { traceCapCreate(cap); traceCapsetAssignCap(CAPSET_OSPROCESS_DEFAULT, i); traceCapsetAssignCap(CAPSET_CLOCKDOMAIN_DEFAULT, i); #if defined(THREADED_RTS) traceSparkCounters(cap); #endif } traceWallClockTime(); traceOSProcessInfo(); To test this you'd want to compare the eventlog in the child with one you get from a normal startup and see if there's anything odd / missing etc. See also ghc-event merge which can merge eventlogs from multiple processes by aligning to a common wall clock time. -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Framework failures
by Simon Peyton Jones 18 Feb '14

18 Feb '14

I'm getting framework failures from the perf/ tests. Example below. Anyone know what is going on? Simon =====> T5837(normal) 1825 of 3901 [0, 0, 11] cd ./perf/compiler && '/5playpen/simonpj/HEAD-1/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5837.hs -ftype-function-depth=50 +RTS -V0 -tT5837.comp.stats --machine-readable -RTS >T5837.comp.stderr 2>&1 Failed to find field: bytes allocated *** framework failure for T5837(normal) do_test exception

3 3

RE: [commit: ghc] master: Fix #8754 in a round-about way. (5023c91)
by Simon Peyton Jones 17 Feb '14

17 Feb '14

Austin, eek... you really need a Note [Need to initialise the hooks], a significant comment, and an explicit mention of this ticket. Otherwise someone in 2 yrs time will have no clue why that lonely call to defaultsHook is so important, nor will be confident enough to remove it when the hookery is done better. I have gotten into habit of writing a Note about virtually any fix. After all, it is by definition not obvious or we'd have got it right the first time. And I have too often re-invented the wheel when looking at Note-free code; or thanked the author when I read a Note and thought "ah, *that's* why!". I wrote up some of this here https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle I don't think the commit log is enough. git annotate may or may not lead you to the right comment, depending on how heavily modified that code is. Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 17 February 2014 07:49 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Fix #8754 in a round-about way. (5023c91) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/5023c91780e90947680fe0640f7564 | a4f6448bea/ghc | | >--------------------------------------------------------------- | | commit 5023c91780e90947680fe0640f7564a4f6448bea | Author: Austin Seipp <austin(a)well-typed.com> | Date: Sun Feb 16 19:10:16 2014 -0600 | | Fix #8754 in a round-about way. | | For some reason on OS X, it seems like -Bsymbolic (which we use for | hooks into the RTS) isn't working, which results in #8754, where | stats | don't work because defaultHooks doesn't initialize the stats flag. | This | seems to work on Linux static/dynamically, but only on OS X | statically. | | After talking with Simon, really, the entire hooks thing is a bit | fragile. For now, we just work around it (since GHCi is dynamically | linked) by calling into the defaultHooks ourselves when GHC starts. | | Signed-off-by: Austin Seipp <austin(a)well-typed.com> | | | >--------------------------------------------------------------- | | 5023c91780e90947680fe0640f7564a4f6448bea | ghc/Main.hs | 4 ++++ | 1 file changed, 4 insertions(+) | | diff --git a/ghc/Main.hs b/ghc/Main.hs | index 868042b..1aa6553 100644 | --- a/ghc/Main.hs | +++ b/ghc/Main.hs | @@ -1,4 +1,5 @@ | {-# OPTIONS -fno-warn-incomplete-patterns -optc-DNON_POSIX_SOURCE #-} | +{-# LANGUAGE ForeignFunctionInterface #-} | | ----------------------------------------------------------------------- | ------ | -- | @@ -76,6 +77,7 @@ import Data.Maybe | | main :: IO () | main = do | + defaultsHook | hSetBuffering stdout LineBuffering | hSetBuffering stderr LineBuffering | GHC.defaultErrorHandler defaultFatalMessager defaultFlushOut $ do @@ | -818,3 +820,5 @@ unknownFlagsErr fs = throwGhcException $ UsageError $ | concatMap oneError fs | (case fuzzyMatch f (nub allFlags) of | [] -> "" | suggs -> "did you mean one of:\n" ++ unlines (map (" " ++) | suggs)) | + | +foreign import ccall safe "defaultsHook" defaultsHook :: IO () | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

Re: [commit: packages/base] master: Implement foldl with foldr (b63face)
by Simon Marlow 17 Feb '14

17 Feb '14

This worries me a bit. If foldl isn't inlined, I get a less efficient version, so it has to be inlined everywhere. So -O0 code gets worse, and binary sizes for -O1+ get bigger - foldl, sum, and product are now INLINE. What I'm arguing is that we should have more flexibility to *not* inline things (INLINABLE is much better than INLINE), and when not inlining things we should be calling an efficient version of the function. This is why map is not defined in terms of foldr, for instance. Cheers, Simon On 10/02/2014 13:52, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/base > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/b63facef165b957183b65604ef99b2b85… > >> --------------------------------------------------------------- > > commit b63facef165b957183b65604ef99b2b8574747a5 > Author: Joachim Breitner <mail(a)joachim-breitner.de> > Date: Tue Jan 28 14:31:05 2014 +0100 > > Implement foldl with foldr > > together with the call arity analysis and the following patch (about inlining > maximum), we get nice benefits from fusing foldl and foldl' with good > producers: > > Min -0.1% -74.5% -6.8% -8.3% -50.0% > Max +0.2% 0.0% +38.5% +38.5% 0.0% > Geometric Mean -0.0% -4.1% +7.7% +7.7% -0.8% > > Because this depends on a compiler optimisation, we have to watch out for cases > where this is not an improvements, and whether they occur in the wild. > > >> --------------------------------------------------------------- > > b63facef165b957183b65604ef99b2b8574747a5 > Data/List.hs | 34 +++++++++------------------------- > GHC/List.lhs | 13 +++++++------ > 2 files changed, 16 insertions(+), 31 deletions(-) > > diff --git a/Data/List.hs b/Data/List.hs > index 130ceb2..4796055 100644 > --- a/Data/List.hs > +++ b/Data/List.hs > @@ -1,5 +1,5 @@ > {-# LANGUAGE Trustworthy #-} > -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-} > +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-} > > ----------------------------------------------------------------------------- > -- | > @@ -989,10 +989,11 @@ unfoldr f b = > -- ----------------------------------------------------------------------------- > > -- | A strict version of 'foldl'. > -foldl' :: (b -> a -> b) -> b -> [a] -> b > -foldl' f z0 xs0 = lgo z0 xs0 > - where lgo z [] = z > - lgo z (x:xs) = let z' = f z x in z' `seq` lgo z' xs > +foldl' :: forall a b . (b -> a -> b) -> b -> [a] -> b > +foldl' k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> z `seq` fn (k z v)) (id :: b -> b) xs z0 > +-- Implementing foldl' via foldr is only a good idea if the compiler can optimize > +-- the resulting code (eta-expand the recursive "go"), so this needs -fcall-arity! > +-- Also see #7994 > > -- | 'foldl1' is a variant of 'foldl' that has no starting value argument, > -- and thus must be applied to non-empty lists. > @@ -1008,32 +1009,15 @@ foldl1' _ [] = errorEmptyList "foldl1'" > -- ----------------------------------------------------------------------------- > -- List sum and product > > -{-# SPECIALISE sum :: [Int] -> Int #-} > -{-# SPECIALISE sum :: [Integer] -> Integer #-} > -{-# INLINABLE sum #-} > -{-# SPECIALISE product :: [Int] -> Int #-} > -{-# SPECIALISE product :: [Integer] -> Integer #-} > -{-# INLINABLE product #-} > --- We make 'sum' and 'product' inlinable so that we get specialisations > --- at other types. See, for example, Trac #7507. > - > -- | The 'sum' function computes the sum of a finite list of numbers. > sum :: (Num a) => [a] -> a > -- | The 'product' function computes the product of a finite list of numbers. > product :: (Num a) => [a] -> a > -#ifdef USE_REPORT_PRELUDE > + > +{-# INLINE sum #-} > sum = foldl (+) 0 > +{-# INLINE product #-} > product = foldl (*) 1 > -#else > -sum l = sum' l 0 > - where > - sum' [] a = a > - sum' (x:xs) a = sum' xs (a+x) > -product l = prod l 1 > - where > - prod [] a = a > - prod (x:xs) a = prod xs (a*x) > -#endif > > -- ----------------------------------------------------------------------------- > -- Functions on strings > diff --git a/GHC/List.lhs b/GHC/List.lhs > index b7b78c7..e004ded 100644 > --- a/GHC/List.lhs > +++ b/GHC/List.lhs > @@ -1,6 +1,6 @@ > \begin{code} > {-# LANGUAGE Trustworthy #-} > -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-} > +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-} > {-# OPTIONS_HADDOCK hide #-} > > ----------------------------------------------------------------------------- > @@ -178,11 +178,12 @@ filterFB c p x r | p x = x `c` r > -- can be inlined, and then (often) strictness-analysed, > -- and hence the classic space leak on foldl (+) 0 xs > > -foldl :: (b -> a -> b) -> b -> [a] -> b > -foldl f z0 xs0 = lgo z0 xs0 > - where > - lgo z [] = z > - lgo z (x:xs) = lgo (f z x) xs > +foldl :: forall a b. (b -> a -> b) -> b -> [a] -> b > +{-# INLINE foldl #-} > +foldl k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> fn (k z v)) (id :: b -> b) xs z0 > +-- Implementing foldl via foldr is only a good idea if the compiler can optimize > +-- the resulting code (eta-expand the recursive "go"), so this needs -fcall-arity! > +-- Also see #7994 > > -- | 'scanl' is similar to 'foldl', but returns a list of successive > -- reduced values from the left: > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

3 4

Re: [commit: packages/base] master: Implement foldl with foldr (b63face)
by Simon Marlow 17 Feb '14

17 Feb '14

This worries me a bit. If foldl isn't inlined, I get a less efficient version, so it has to be inlined everywhere. So -O0 code gets worse, and binary sizes for -O1+ get bigger - foldl, sum, and product are now INLINE. What I'm arguing is that we should have more flexibility to *not* inline things (INLINABLE is much better than INLINE), and when not inlining things we should be calling an efficient version of the function. This is why map is not defined in terms of foldr, for instance. Cheers, Simon On 10/02/2014 13:52, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/base > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/b63facef165b957183b65604ef99b2b85… > >> --------------------------------------------------------------- > > commit b63facef165b957183b65604ef99b2b8574747a5 > Author: Joachim Breitner <mail(a)joachim-breitner.de> > Date: Tue Jan 28 14:31:05 2014 +0100 > > Implement foldl with foldr > > together with the call arity analysis and the following patch (about inlining > maximum), we get nice benefits from fusing foldl and foldl' with good > producers: > > Min -0.1% -74.5% -6.8% -8.3% -50.0% > Max +0.2% 0.0% +38.5% +38.5% 0.0% > Geometric Mean -0.0% -4.1% +7.7% +7.7% -0.8% > > Because this depends on a compiler optimisation, we have to watch out for cases > where this is not an improvements, and whether they occur in the wild. > > >> --------------------------------------------------------------- > > b63facef165b957183b65604ef99b2b8574747a5 > Data/List.hs | 34 +++++++++------------------------- > GHC/List.lhs | 13 +++++++------ > 2 files changed, 16 insertions(+), 31 deletions(-) > > diff --git a/Data/List.hs b/Data/List.hs > index 130ceb2..4796055 100644 > --- a/Data/List.hs > +++ b/Data/List.hs > @@ -1,5 +1,5 @@ > {-# LANGUAGE Trustworthy #-} > -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-} > +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-} > > ----------------------------------------------------------------------------- > -- | > @@ -989,10 +989,11 @@ unfoldr f b = > -- ----------------------------------------------------------------------------- > > -- | A strict version of 'foldl'. > -foldl' :: (b -> a -> b) -> b -> [a] -> b > -foldl' f z0 xs0 = lgo z0 xs0 > - where lgo z [] = z > - lgo z (x:xs) = let z' = f z x in z' `seq` lgo z' xs > +foldl' :: forall a b . (b -> a -> b) -> b -> [a] -> b > +foldl' k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> z `seq` fn (k z v)) (id :: b -> b) xs z0 > +-- Implementing foldl' via foldr is only a good idea if the compiler can optimize > +-- the resulting code (eta-expand the recursive "go"), so this needs -fcall-arity! > +-- Also see #7994 > > -- | 'foldl1' is a variant of 'foldl' that has no starting value argument, > -- and thus must be applied to non-empty lists. > @@ -1008,32 +1009,15 @@ foldl1' _ [] = errorEmptyList "foldl1'" > -- ----------------------------------------------------------------------------- > -- List sum and product > > -{-# SPECIALISE sum :: [Int] -> Int #-} > -{-# SPECIALISE sum :: [Integer] -> Integer #-} > -{-# INLINABLE sum #-} > -{-# SPECIALISE product :: [Int] -> Int #-} > -{-# SPECIALISE product :: [Integer] -> Integer #-} > -{-# INLINABLE product #-} > --- We make 'sum' and 'product' inlinable so that we get specialisations > --- at other types. See, for example, Trac #7507. > - > -- | The 'sum' function computes the sum of a finite list of numbers. > sum :: (Num a) => [a] -> a > -- | The 'product' function computes the product of a finite list of numbers. > product :: (Num a) => [a] -> a > -#ifdef USE_REPORT_PRELUDE > + > +{-# INLINE sum #-} > sum = foldl (+) 0 > +{-# INLINE product #-} > product = foldl (*) 1 > -#else > -sum l = sum' l 0 > - where > - sum' [] a = a > - sum' (x:xs) a = sum' xs (a+x) > -product l = prod l 1 > - where > - prod [] a = a > - prod (x:xs) a = prod xs (a*x) > -#endif > > -- ----------------------------------------------------------------------------- > -- Functions on strings > diff --git a/GHC/List.lhs b/GHC/List.lhs > index b7b78c7..e004ded 100644 > --- a/GHC/List.lhs > +++ b/GHC/List.lhs > @@ -1,6 +1,6 @@ > \begin{code} > {-# LANGUAGE Trustworthy #-} > -{-# LANGUAGE CPP, NoImplicitPrelude, MagicHash #-} > +{-# LANGUAGE CPP, NoImplicitPrelude, ScopedTypeVariables, MagicHash #-} > {-# OPTIONS_HADDOCK hide #-} > > ----------------------------------------------------------------------------- > @@ -178,11 +178,12 @@ filterFB c p x r | p x = x `c` r > -- can be inlined, and then (often) strictness-analysed, > -- and hence the classic space leak on foldl (+) 0 xs > > -foldl :: (b -> a -> b) -> b -> [a] -> b > -foldl f z0 xs0 = lgo z0 xs0 > - where > - lgo z [] = z > - lgo z (x:xs) = lgo (f z x) xs > +foldl :: forall a b. (b -> a -> b) -> b -> [a] -> b > +{-# INLINE foldl #-} > +foldl k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> fn (k z v)) (id :: b -> b) xs z0 > +-- Implementing foldl via foldr is only a good idea if the compiler can optimize > +-- the resulting code (eta-expand the recursive "go"), so this needs -fcall-arity! > +-- Also see #7994 > > -- | 'scanl' is similar to 'foldl', but returns a list of successive > -- reduced values from the left: > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Re: 7.8.1-candidate fail
by Jan Stolarek 17 Feb '14

17 Feb '14

I had the same problem on Debian Squeeze: https://ghc.haskell.org/trac/ghc/ticket/8666 What is your distro? CCing ghc-devs. Janek Dnia czwartek, 6 lutego 2014, Sergei Meshveliani napisał: > Dear GHC team, > > I am trying to test ghc-7.8.20140130-src.tar.bz2 > > I make it from source with ghc-7.6.3 on Debian Linux (64 bit). > > ./configure looks all right. > > And `make' reports after 40 minutes: > > ------------------------------------------------------- > ... > ... > "inplace/bin/ghc-stage1" -optc-Ilibraries/integer-gmp/. > -optc-I'/home/mechvel/g..... > ... > ... > /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation > R_X86_64_32 against `__gmpz_sub' can not be used when making a shared > object; recompile with -fPIC > libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value > collect2: ld returned 1 exit status > make[1]: *** > [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0\ > -ghc7.8.20140130.so] Error 1 > ------------------------------------------------------- > > > What might this mean? Need I to install a fresher libgmp ? > > Thanks, > > ------ > Sergei > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 2

Re: Overlapping names in GHC: ConLike
by Carter Schonwald 15 Feb '14

15 Feb '14

BijectionLike, InvertableCon ReversableConstructor InvertableLike Dualable DualLike DuelFoil -- I kid basically something about how patternSynonyms and normal type constructors have this "bjiective" (ish?) quality On Fri, Feb 14, 2014 at 11:10 PM, Dr. ÉRDI Gergő <gergo(a)erdi.hu> wrote: > Can we force some more elements of that lazy stream? > On Feb 15, 2014 12:09 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> > wrote: > >> ConstructorAble ? (I'm happy to come up with a whole list of >> candidates). :-) >> >> On Friday, February 14, 2014, Dr. ERDI Gergo <gergo(a)erdi.hu> wrote: >> >>> On Thu, 13 Feb 2014, Carter Schonwald wrote: >>> >>> Caseable? PatternLike? >>>> >>> >>> The reason I went with ConLike originally (apart from not noticing the >>> clash) was that (bidirectional) pattern synonyms can also be used in >>> expressions, so they behave like constructors in both contexts. >> >>

1 0