- ghc-devs - Haskell.org

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

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