- ghc-devs - Haskell.org

ORF and renamer
by Alan & Kim Zimmerman 23 Feb '16

23 Feb '16

I am working on updating HaRe for GHC 8.0.1, and have hit an issue with the following file --------------------------- module Field1 where --Rename field name 'pointx' to 'pointx1' data Point = Pt {pointx, pointy :: Float} absPoint :: Point -> Float absPoint p = sqrt (pointx p * pointx p + pointy p * pointy p) -------------------------- It seems that after the renamer, each of the three instances of `pointx` has a different `nameUnique` value. Is this because the final resolution is now done during type checking? If so it makes the RenamedSource much harder to work with. Alan

2 3

"Excuse me, I think this i my stop..." - Resigning from the Platform
by Mark Lentczner 22 Feb '16

22 Feb '16

I think this is the right time for me to exit: The truth is, I still can't bring myself to use a version of Haskell post the Foldable-Traversable-aPocalypse, let alone some future Haskell after the changes now in the works. My personal machines are all still 7.8. My personal projects are all pre-FTP. The Haskell I love to code in, the Haskell I'm passionate about, the Haskell I've advocated for real world use, and the Haskell I like to teach, is 7.8, pre-FTP. It's not that I'm dead set against change and evolution in a language, or even breaking changes. But FTP and beyond are changes that have lost the balance that Haskell had between abstraction and clarity, between elaborate and practical engineering. I don't see any restraint going forward, so I'm getting off the train. This puts me in an odd position with respect to Haskell Platform: I find myself building the Platform for a version of Haskell that I don't use. This isn't healthy for either the Platform or me. Hence, I'm resigning as release manager. I am sad because I believed that Haskell's path to much wider adoption was within reach. Now, especially with the ramping up of the Haskell Prime committee, which seems preordained to codify FTP and beyond into standard, we are approaching our Algol 68 moment: Building a major language revision with less opportunity than it's predecessor. I'll still see you 'round at meet-ups and conferences. I'll just be coding with an older accent. - Mark "mzero" Lentczner

7 8

Fwd: Compiling Core Haskell using GHC API
by Marek Wawrzos 20 Feb '16

20 Feb '16

Hello, I'm trying to compile some module with GHC API. I'm going to feed GHC with Core generated by me. So far is noticed, that function compileCoreToObj ends with an runtime error on each call. In spide of this function produces some *.o and *.hi files. However, produced interface file does not contain any item in exports field, what makes compiled module unusable. Because of this problem, I tried to achieve my goal by using steps described here: https://wiki.haskell.org/GHC/As_a_library (the second example) I was able to print out Core produced form file. If I'm not wrong, modifying structures passing on between sequent calls does not effect on produced *.hi and *.o files. Both files are generated by `load LoadAllTargets' call, and further calls (parseModule, loadModule, ...) does not effect on generated files. Could You give me any advices in that topic? Am I right about compileCoreToObj and functions mentioned above? Best Regards, Marek

2 3

Advice for #11475
by Jonas Scholl 19 Feb '16

19 Feb '16

Hello GHC-Devs, I am currently giving #11475 a try. However I hit a few problems and wanted to ask for a bit of advice about how to proceed. I already can handle the following: case x of A y -> e1 _ -> ....(case x of B -> r2 C -> r3) ... My first problem then was the following construct: case (case ... of ... -> Left x) of Left y -> ... Or more simple: case Left x of Left y -> ... So I have to check which constructors the scrutinee may return. I know the simplifier has to implement such logic somewhere but did not want to use the implementation for two reasons: - I didn't know where to find it - If GHC uses the same test to prune impossible alternatives and to check if they were pruned correctly, extending the linter is useless. A bug in the test code will cause also cause a bug in the linter. So I implemented such a test myself, but now I am stuck at something like this: foo a b = a : b bar = ... case foo a b of (:) x y -> ... I cannot see through foo, so I assume it may return (:) and []. The simplifier on the other hand is able to see through foo and did remove the [] case, causing my current implementation to throw an incorrect lint error. How can I get a list/set of all possible AltCons returned by a function/constant? Or a list of the impossible ones? I tried to get some information from the unfolding of a variable, but it seems like unfoldings are only attached to top-level names. Jonas

2 1

Missing definitions of associated types
by David Feuer 18 Feb '16

18 Feb '16

It seems to be that a missing associated type definition should be an error, by default, rather than a warning. The current behavior under those circumstances strikes me as very strange, particularly for data families and particularly in the presence of overlapping. {-# LANGUAGE TypeFamilies #-} class Foo a where data Assoc a foo :: proxy a -> Assoc a instance {-# OVERLAPPABLE #-} Foo a where data Assoc a = AssocGeneral foo _ = AssocGeneral instance {-# OVERLAPS #-} Foo Char where foo _ = AssocGeneral blah :: Assoc Char blah = foo (Proxy :: Proxy Char) This compiles with just a warning because Assoc Char *falls through* to the general case. WAT? This breaks all my intuition about what associated types are supposed to be about.

2 2

Build failures with -DDEBUG
by Thomas Miedema 18 Feb '16

18 Feb '16

Simon, the commits you pushed today don't validate with -DDEBUG. Unexpected failures: patsyn/should_compile MoreEx [exit code non-0] (normal) patsyn/should_compile T11224b [exit code non-0] (normal) polykinds MonoidsTF [exit code non-0] (normal) polykinds T11480b [exit code non-0] (normal) polykinds T11523 [exit code non-0] (normal) typecheck/should_fail TcCoercibleFail [stderr mismatch] (normal) TcCoercibleFail timed out, and the others all hit the following debug assert: =====> T11224b(normal) 2510 of 5029 [0, 0, 0] Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160218 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1932:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:1991:17 in ghc:TyCoRep substTys, called at compiler/types/TyCoRep.hs:2012:14 in ghc:TyCoRep substTheta, called at compiler/typecheck/TcPatSyn.hs:255:20 in ghc:TcPatSyn in_scope InScope {d_ap0 c_apv} tenv [ap1 :-> c_apv[tau:5]] tenvFVs [aps :-> t_aps[tau:1], apv :-> c_apv[tau:5]] cenv [] cenvFVs [] tys [] cos [] Complete log from Travis: https://s3.amazonaws.com/archive.travis-ci.org/jobs/110115377/log.txt -- Thomas

2 1

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?
by Andrey Mokhov 18 Feb '16

18 Feb '16

Thomas Tuegel <ttuegel(a)gmail.com> writes: > > What exactly does the pre-process phase do, anyways? > It runs the appropriate pre-processor (Alex, Happy, c2hs, etc.) for modules > that require it. It's slow because of the way the process is carried out: For > each module in the package description, Cabal tries to find an associated .hs > source file in the hs-source-dirs. If it cannot, it looks for a file with an > extension matching one of the pre-processors it knows about. If it finds one, > it runs the corresponding program if the output files are missing or outdated. Interesting! In the new Shake-based build system we also need to automagically generate .hs files using Alex et al. My first implementation was slow but then I realised that it is possible to scan the source tree only once and remember where all .hs/.x/etc files are. This brought down the complexity from quadratic to linear in my case -- maybe this could be reused in cabal too? By the way, there seem to be a fair amount of code & functionality overlap in cabal and the new build system. We might want to look into this once the build system becomes more stable. Cheers, Andrey

3 3

Strict Haskell
by Simon Peyton Jones 18 Feb '16

18 Feb '16

Johan Consider this with -XStrict f y = let Just x = blah[y] in body[y,x] Suppose that in a call to f, · blah returns Nothing · but body does not use x Should f succeed? For sure, blah will be evaluated to HNF before body is started, but is the match against Just done strictly too? According to our current semantics, in the match against Just is not done strictly, so the call should succeed. I think that’s unexpected and probably wrong. Here’s the semantics http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#recu… The translation for !(Just x) = blah ð (FORCE) v = blah; Just x = v (and add a seq on v) ð (SPLIT) v = blah; x = case v of Just x -> x So we finish up with f y = let v = blah[y] in let x = case v of Just x -> x in v `seq` body[y,x] I don’t think that’s what you intended. If the pattern can fail, I think we want the FORCE step to say this: Replace any binding !p = e with v = case e of p -> (v1,..,vn); (v1,..,vn) = v and replace e0 with v seq e0, where v is fresh and v1..vn are the variable(s) bound by p (Compare with the text at the above link.) Do you agree? Simon

1 0

Fwd: Is anything being done to remedy the soul crushing compile times of GHC?
by Manuel M T Chakravarty 18 Feb '16

18 Feb '16

There is currently an interesting discussion on Reddit on GHC compile times https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_… I feel that this is a serious problem; so, it probably ought to be discussed here as well. Manuel

11 19

Installing Cabal for GHC 8.0 release candidates
by Ben Gamari 17 Feb '16

17 Feb '16

Hello everyone, Our wonderful Cabal release manager Mikhail Glushenkov has kindly uploaded candidate releases of Cabal and cabal-install for use by GHC 8.0 release candidate users. Now updating to a GHC 8.0-compatible Cabal/cabal-install should be as simple as, cabal install \ http://hackage.haskell.org/package/Cabal-1.23.1.0/candidate/Cabal-1.23.1.0.… \ http://hackage.haskell.org/package/cabal-install-1.23.0.0/candidate/cabal-i… Happy testing! Cheers, - Ben

2 2