- ghc-devs - Haskell.org

first version of RC2 has problems with lack of dynamic problems at least on the Mac
by George Colpitts 27 Feb '14

27 Feb '14

Hi After installing the first version of RC2 I ran into the following problem cabal install vector Resolving dependencies... Configuring vector-0.10.9.1... ... [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package primitive-0.5.2.1 ... <command line>: can't load .so/.DLL for: libHSprimitive-0.5.2.1.dylib (dlopen(libHSprimitive-0.5.2.1.dylib, 9): image not found) There seems to be a general problem that the install did not produce any dynamic libraries at least on the Mac: ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib: HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a libHScpphs-1.18.2_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib: Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a libHShashable-1.2.1.0_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib: HShscolour-1.20.3.o Language libHShscolour-1.20.3.a libHShscolour-1.20.3_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib: Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a Data include libHSprimitive-0.5.2.1_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib: Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib: Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib: Data libHSunordered-containers-0.2.3.3.a HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a

2 1

RC2 release imminent
by Austin Seipp 27 Feb '14

27 Feb '14

Hello all, Just as a quick update, the RC2 release will be soon. I plan on fixing #8736 and releasing it. #8696 will come shortly with the final release. I'll follow up when a source tarball is available, so Pali and Karel can build binaries. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

8 17

SPARC: why it's not registerised anymore?
by Karel Gardas 26 Feb '14

26 Feb '14

Folks, just out of curiosity I'm building latest GHC on SPARC/Solaris and I've noted that current GHCs (7.6 and HEAD) are building unregisterised by default. In the history I remember at least some GHC were registerised and GHC source code also (still) contains SPARC NCG so I'm curious what was the reason behind the switch? Any bug still waiting for a fix? Or just code rotted in a way it's not working any more? Thanks! Karel

2 3

would support for kind equalities enable the following example?
by Carter Schonwald 26 Feb '14

26 Feb '14

Hey all, I've a use case in my code where It looks like it might be an example of something that won't compile until we have type level GADTs I'm essentially writing a vector api that allows certain args to be mutable, pure or "dont care". (dont care = that they're treated as being immutable). I'm using GADTs to model this. (using GADTs rather than type classes partly because I want to make sure type inference works out nicely, and partly to see how far i can go while not adding any new type classes) data Eff :: * -> * where Pure :: Eff () Mut :: s -> Eff s data EVector :: * -> * -> * where PureVector :: S.Vector el -> EVector Pure el MutVector :: SM.MVector s el -> EVector (Mut s) el the above doesn't work because DataKinds only works at kind * currently, however i can defunctionalize it to the following (while making it a tad less pretty) and it then works data Eff = Pure | Mut data EVector :: Eff -> * -> * -> * where PureVector :: S.Vector el -> EVector Pure () el MutVector :: SM.MVector s el -> EVector Mut s el am i correct in thinking that the first example *should* be possible once we have fancier kind machinery (kind equalities and type level GADTs?)? I suspect I'll be hitting *A LOT* more examples like the above, and if theres any ways I can help push this along on the research or engineering side, I please tell me :) thanks! -Carter

2 4

Pretty-printing of type variables (Help needed for #8776)
by Dr. ERDI Gergo 26 Feb '14

26 Feb '14

Hi, Ticket #8776 (https://ghc.haskell.org/trac/ghc/ticket/8776) is about the output formatting of pattern synonym type signatures. With -dppr-debug, the problematic signature looks like this: (base:GHC.Num.Num{tc 2b} t{tv aQa} [sk], ghc-prim:GHC.Classes.Eq{tc 23} t{tv aQb} [sk]) => main:Main.P{d rs2} :: main:Main.A{tc rpC} t{tv aQa} [sk] t1{tv aQb} [sk] The problem is that the two type variables occuring in the provided context both have "t" as their user-visible name; even though the second one is projected as "t1" in the tau type on the right-hand side. The code to generate this output is in HsBinds.ppr_sig, using pprPatSynSig which just adds the "pattern" keyword and the separating "=>" symbols etc: ppr_sig (PatSynSig name arg_tys ty prov req) = pprPatSynSig (unLoc name) False args (ppr ty) (pprCtx prov) (pprCtx req) where args = fmap ppr arg_tys pprCtx lctx = case unLoc lctx of [] -> Nothing ctx -> Just (pprHsContextNoArrow ctx) My guess is that the problem is 'pprHsContextNoArrow' projects individual constraints one-by-one and so doesn't notice the name clash on 't' between the two constraints in the example; whereas 'ppr ty' walks the whole right-hand tau type and thus has the opportunity to maintain a set of type variable names used. My question is, where is that logic, and how can I use that in this instance? My hope is to be shown a design where I can run 'ppr ty', 'pprCtx prov' and 'pprCtx req' in the same "naming environment" (I hope such a thing exists) so that they use a consistent naming scheme. This looks like a problem that must have popped up at a lot of places in GHC already and must have an idiomatic solution. Thanks, Gergo

1 0

cpphs bug
by Roman Cheplyaka 24 Feb '14

24 Feb '14

Hi Malcolm, This appears to be a cpphs bug. For the following code #define x (1 == 1) #if x YES #else NO #endif cpphs 1.18.1 prints NO, while the expected output (and the output GNU cpp produces) is YES. If parentheses around 1 == 1 are removed, or if x is inlined manually, then cpphs correctly prints YES. This affects GHC 7.8 users in a serious way: GHC 7.8 uses cpphs, and the above code is a simplified version of macros generated by cabal. For this reason, for instance, type-eq 0.4.1 cannot be build by GHC 7.8 RC1, despite the proper CPP guards. Roman

3 4

Change in rendering of [] in GADTs
by Mateusz Kowalczyk 22 Feb '14

22 Feb '14

While running Haddock tests today, we noticed that the output for a test with GADTs changed. See the test file in the bottom. We used to render ‘Nil :: Pattern '[]’ as ‘Pattern []’ but it now renders as ‘Pattern `[]`’. The change happened within last 2 days and I'm guessing it's d3af9807ca8a1db0bc9298ea50895ee9df55edb7 that made the change. Should this be something that we fix on Haddock end or should it be left with the new rendering? I'm unsure whether the previous rendering wasn't better or not. The Haddock test suite is not ran as part of GHC validate process so it the failure slipped by. The file is: {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} module AdvanceTypes where data Pattern :: [*] -> * where Nil :: Pattern '[] Cons :: Maybe h -> Pattern t -> Pattern (h ': t) -- Mateusz K.

1 0

32-bit Linux perf failures
by Mateusz Kowalczyk 20 Feb '14

20 Feb '14

Greetings, I just ran validate with current HEAD (2b34947b60069e51abfcada9c45a6d7b590f5a2b) and I have quite a few perf failures. Perhaps these need tweaking? I know that 32-bit numbers were neglected in the past. The Haddock numbers have been complaining for a few weeks now but I think everything else is fairly new. Here is the end of the log: Unexpected results from: TEST="T876 T7954 T8766 T1969 T5631 T783 T3294 haddock.Cabal haddock.compiler haddock.base T3924" OVERALL SUMMARY for test run started at Thu Feb 20 00:54:28 2014 GMT 0:18:11 spent to go through 3903 total tests, which gave rise to 15265 test cases, of which 11699 were skipped 28 had missing libraries 3469 expected passes 58 expected failures 3 caused framework failures 0 unexpected passes 11 unexpected failures Unexpected failures: ../../libraries/base/tests T8766 [stat too good] (normal) callarity/perf T3924 [stat too good] (normal) perf/compiler T1969 [stat too good] (normal) perf/compiler T3294 [stat too good] (normal) perf/compiler T5631 [stat too good] (normal) perf/compiler T783 [stat too good] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat too good] (normal) perf/should_run T7954 [stat too good] (normal) perf/should_run T876 [stat too good] (normal) -- Mateusz K.

3 3

Re: [commit: ghc] master: Update to primitive-0.5.2.1 (47d725f)
by Karel Gardas 20 Feb '14

20 Feb '14

Herbert, thanks for merging this, but this is somehow not working for me. I see this patch in ghc repo after ./sync-all pull, but my libraries/primitive is still on 5ae8fbb8131ccc934cadd29cc1d17298cfdaef4b commit from November 2013 Is there anything special I need to do in order to update git submodules? Thanks! Karel On 02/19/14 11:28 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/47d725f29376fa1be726e913cdf3dd69c… > >> --------------------------------------------------------------- > > commit 47d725f29376fa1be726e913cdf3dd69c46327c2 > Author: Herbert Valerio Riedel<hvr(a)gnu.org> > Date: Wed Feb 19 23:26:30 2014 +0100 > > Update to primitive-0.5.2.1 > > This contains a compile-fix for Solaris > > Signed-off-by: Herbert Valerio Riedel<hvr(a)gnu.org> > > >> --------------------------------------------------------------- > > 47d725f29376fa1be726e913cdf3dd69c46327c2 > libraries/primitive | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libraries/primitive b/libraries/primitive > index 5ae8fbb..be63ee1 160000 > --- a/libraries/primitive > +++ b/libraries/primitive > @@ -1 +1 @@ > -Subproject commit 5ae8fbb8131ccc934cadd29cc1d17298cfdaef4b > +Subproject commit be63ee15d961dc1b08bc8853b9ff97708551ef36 > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

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