- Glasgow-haskell-users

Overloaded record fields
by Adam Gundry 18 Jul '13

18 Jul '13

Hi everyone, I am implementing an overloaded record fields extension for GHC as a GSoC project. Thanks to all those who gave their feedback on the original proposal! I've started to document the plan on the GHC wiki: http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan If you have any comments on the proposed changes, or anything is unclear about the design, I'd like to hear from you. Thanks, Adam Gundry

19 40

implicit params in instance contexts
by Ganesh Sittampalam 16 Jul '13

16 Jul '13

Hi, It seems that from GHC 7.4, the prohibition on implicit parameter constraints in instance declarations has been relaxed. The program below gives the error "Illegal constraint ?fooRev::Bool" in GHC 7.2.1 but loads fine in GHC 7.4.2 and GHC 7.6.2. I can't spot anything about this in the release notes, and the documentation (http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/other-type-extension…) still says "You can't have an implicit parameter in the context of a class or instance declaration." So I wonder if this happened by accident, perhaps as part of the ConstraintKinds work or similar? I've wanted this feature a few times so if it's going to stay I might start using it. However it is a bit dangerous, so if it was added by accident it might warrant some discussion before deciding to keep it. For example as the value "set2" below shows, it can be used to violate datatype invariants. Cheers, Ganesh {-# LANGUAGE ImplicitParams #-} module Ord where import Data.Set ( Set ) import qualified Data.Set as Set newtype Foo = Foo Int deriving (Eq, Show) instance (?fooRev :: Bool) => Ord Foo where Foo a `compare` Foo b = if ?fooRev then b `compare` a else a `compare` b set1 = let ?fooRev = False in Set.fromList [Foo 1, Foo 3] set2 = let ?fooRev = True in Set.insert (Foo 2) set1 -- Ord> set2 -- fromList [Foo 2,Foo 1,Foo 3]

4 3

A possible alternative to dot notation for record access
by Judah Jacobson 12 Jul '13

12 Jul '13

Hi all, I had a quick idea about record field syntax as specified in the GSoC project plan: http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan . Instead of "f.x" (to access field x of record f), maybe we could write "f{x}" as the record selection. That is, we'd reuse the brace notation which is already in place for record updates. Unlike dot notation, this is unambiguous and doesn't conflict with any existing syntax (AFAIK). It would also generalize to "f{x}{y}{z}" instead of "f.x.y.z". This proposal would add two new forms of expressions: f{x} to access field x of data f ({x}) = \f -> f{x} as a field access section Additionally, it seems like record mutation expressions could also have sections: ({x=2}) = \f -> f{x=2} That actually seems useful by itself, regardless of whether we use dot notation for field access. Best, -Judah

10 10

executable stack flag
by Jens Petersen 09 Jul '13

09 Jul '13

Hi, We noticed [1] in Fedora that ghc (7.4 and 7.6) are linking executables (again [2]) with the executable stack flag set. I haven't starting looking at the ghc code yet but wanted to ask first if it is intentional/necessary? (ghc-7.0 doesn't seem to do this.) Having the flag set is considered a bit of a security risk so it would be better if all generated executable did not have it set. I did some very basic testing of various executables, clearing their flags [3] and they all seemed to run ok without the executable stack flag set but I can't claim to have tested very exhaustively. (I thought perhaps it might be related to TemplateHaskell for example but even those executables seem to work, though I am sure I have not exercised all the code paths.) Does someone know the current status of this? Will anything break if the flag is not set? Is it easy to patch ghc to not set the flag? Does it only affect the NCG backend? Thanks, Jens [1] https://bugzilla.redhat.com/show_bug.cgi?id=973512 [2] http://ghc.haskell.org/trac/ghc/ticket/703 [3] using "execstack -c"

2 2

Field accessor type inference woes
by Edward Kmett 05 Jul '13

05 Jul '13

It strikes me that there is a fairly major issue with the record proposal as it stands. Right now the class class Has (r :: *) (x :: Symbol) (t :: *) can be viewed as morally equivalent to having several classes class Foo a b where foo :: a -> b class Bar a b where bar :: a -> b for different fields foo, bar, etc. I'll proceed with those instead because it makes it easier to show the issue today. When we go to compose those field accessors, you very quickly run into a problem due to a lack of functional dependencies: When you go to define fooBar = foo.bar which is perfectly cromulent with existing record field accessors you get a big problem. fooBar :: (Foo b c, Bar a b) => a -> c The b that should occur in the signature isn't on the right hand side, and isn't being forced by any fundeps, so fooBar simply can't be written. Could not deduce (Foo b0 c) arising from a use of `foo' from the context (Bar a b, Foo b c) If you leave off the signature you'll get an ambiguity check error: Could not deduce (Foo b0 c) arising from the ambiguity check for `fooBar' from the context (Bar a b, Foo b c) bound by the inferred type for `fooBar': (Bar a b, Foo b c) => a -> c It strikes me that punting all functional dependencies in the record types to the use of equality constraints has proven insufficient to tackle this problem. You may be able to bandaid over it by including a functional dependency/type family class Has (r :: *) (x :: Symbol) where type Got r x :: * getFld :: r -> Got r x (or to avoid the need for type applications in the first place!) class Has (r :: *) (x :: Symbol) where type Got r x :: * getFld :: p x -> r -> Got r x This has some annoying consequences though. Type inference can still only flow one way through it, unlike the existing record accessors, and it would cost the ability to 'cheat' and still define 'Has' for universally quantified fields that we might have been able to do with the proposal as it stands. -Edward

6 12

Exposing newtype coercions to Haskell
by Joachim Breitner 04 Jul '13

04 Jul '13

Hi, this is related to http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers#Proposal3. I tried to hack up a little prototype of this, and this “works” now: import GHC.NT newtype Age = Age Int deriving Show ageNT :: NT Age Int ageNT = createNT newtype MyList a = MyList [a] deriving Show myListNT :: NT (MyList a) [a] myListNT = createNT main = do let n = 1 :: Int let a = coerce (sym ageNT) 1 let l1 = [a] let l2 = coerce (listNT ageNT) l1 let l3 = coerce (sym myListNT) l2 print a print l2 print l3 will print Age 1 [1] MyList [1] and no unsafeCoerce and no map is used in the production of this output. The GHC.NT module provides: data NT a b coerce :: NT a b -> a -> b refl :: NT a a sym :: NT a b -> NT b a trans :: NT a b -> NT b c -> NT a c createNT :: NT a b listNT :: NT a b -> NT [a] [b] where createNT takes the place of the "deriving foo :: NT a b" syntax: At compile time, it is checked if its first type argument is a newtype of the second, and the corresponding coercion is inserted, otherwise an error is (well, will be) printed. The idea is that these coercions will be guaranteed to be free (or almost free; I am not sure if the coercion witness (NT a b) will actually be optimized away). The prototype can be found at https://github.com/nomeata/nt-coerce and is implemented as a GHC plugin compatible with GHC 7.6.3 (I chose this route as it means not having to compile GHC). You can check if it works for you via $ ghc -dcore-lint -package ghc --make test.hs && ./test The code itself is, well, at most prototype code quality and contains quite a number of hacks and other warts, mostly due to my inexperience with GHC hacking, and I could make use of some advice. Some more concrete questions: * How do I look up a module (here GHC.NT.Type) and a name therein (NT) in CoreM? I tried to go via getOrigNameCache, but passing the ModuleName name to lookupModuleEnv yielded Nothing, although it seems to me to be precisely the same name that I find in moduleEnvKeys. If I take the ModuleName from that list, it works. Similar problems with the OccEnv. Please see https://github.com/nomeata/nt-coerce/blob/edef9f4d4889dde651bb086e76c576f84… for what I tried (and how I worked around it). This work-around also prevents building the package with cabal right now. * I did not find generic Core traversal functions like traverse :: (Monad m) => (Expr a -> m (Maybe (Expr a))) -> Expr a -> m (Expr a) which I defined in https://github.com/nomeata/nt-coerce/blob/edef9f4d4889dde651bb086e76c576f84…. Are such traversals re-implemented everywhere or did I just not search well enough? * On the core level, once I have a TyCon, I also have all DataCons available. Is there already code present that checks if the currently compiled module really should see the data constructors, i.e. if they are exported? I see code in normaliseFfiType, but that seems to be integrated in the type checker, and it seems I need a GlobalRdrEnv; can I get such a thing in a Core2Core pass? Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

3 10

Re: PSA: GHC can now be built with Clang
by Austin Seipp 01 Jul '13

01 Jul '13

Thanks Manuel! I have an update on this work (I am also CC'ing glasgow-haskell-users, as I forgot last time.) The TL;DR is this: * HEAD will correctly work with Clang 3.4svn on both Linux, and OS X. * I have a small, 6-line patch to Clang to fix the build failure in primitive (Clang was too eager to stringify something.) Once this fix is integrated into Clang (hopefully very soon,) it will be possible to build GHC entirely including all stage2 libraries without any patches. The patch is here: http://llvm.org/bugs/show_bug.cgi?id=16371 - I am hoping this will also make it into XCode 5. * I still have to eliminate some warnings throughout the build, which will require fiddling and a bit of refactoring. The testsuite still probably won't run cleanly on Linux, at least, until this is done I'm afraid (but then again I haven't tried...) As for the infamous ticket #7602, the large performance regression on Mac OS X, I have some numbers finally between my fast-TLS and slow-TLS approach. ./gc_bench.slow-tls 19 500000 5 22 +RTS -H180m -N7 -RTS 395.57s user 173.18s system 138% cpu 6:50.71 total vs ./gc_bench.fast-tls 19 500000 5 22 +RTS -H180m -N7 -RTS 322.98s user 132.37s system 132% cpu 5:44.65 total Now, this probably looks totally awful from a scalability POV. And, well, yeah, it is. But I am almost 100% certain there is something extremely screwy going on with my machine here. I base this on the fact that during gc_bench, kernel_task was eating up about ~600% of my CPU consistently, giving user threads no time to run. I've noticed this with other applications that were totally unrelated too (close tweetbot -> 800% CPU usage,) so I guess it's time to learn DTrace. Or turn it on and off again or something. Ugh. Anyway, if you look at the user times, you get a nice 30% speedup which is about what we expect! On a related note, due to the source code structure at the moment, Linux/Clang hilariously suffers from this same bug. That's because while Clang on Linux supports extremely fast TLS via __thread (like GCC,) it falls back to pthread_getspecific/setspecific. I haven't fixed this yet. It'll happen after I fix #7602 and get it merged in. On my Linux machine, gc_bench also sees a consistent 30% speedup between these two approaches, so I think this is a relatively accurate measurement. Well, as accurate as I can be without running nofib just yet. So if you're just dying to have GHC HEAD built with Clang HEAD on Linux because you've got reasons, you should probably hold on. I also may have a similar, better approach to fixing #7602 that is not entirely as evil and sneaky as crashing the WebKit party. I'll follow up on this soon when I have more info in a separate thread to confer with Simon. With nofib results. I hope. But anyway, 7.8 will be shaping up quite nicely - in particular in the Mac OS X department, I hope. Please feel free to pester me with questions or if you attempt something and it doesn't work. On Tue, Jun 25, 2013 at 7:34 PM, Manuel M T Chakravarty <chak(a)cse.unsw.edu.au> wrote: > Austin, > > Thank you very much for taking care of all these clang issues — that is very helpful! > > Cheers, > Manuel > > Austin Seipp <aseipp(a)pobox.com>: >> Hi all, >> >> As of commit 5dc74f it should now be possible to build a working >> stage1 and stage2 compiler with (an extremely recent) Clang. With some >> caveats. >> >> You can just do: >> >> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang >> $ make >> >> I have done this work on Linux. I don't expect much difficulty on Mac >> OS X, but it needs testing. Ditto with Windows, although Clang/mingw >> is considered experimental. >> >> The current caveats are: >> >> * The testsuite will probably fail everywhere, because of some >> warnings that happen during the linking phase when you invoke the >> built compiler. So the testsuite runner will probably be unhappy. >> Clang is very noisy about unused options, unlike GCC. That needs to be >> fixed somewhere in DriverPipeline I'd guess, but with some >> refactoring. >> * Some of the stage2 libraries don't build due to a Clang bug. These >> are vector/primitive/dph so far. >> * There is no buildbot or anything to cover it. >> >> You will need a very recent Clang. Due to this bug (preventing >> primitive etc from building,) you'll preferably want to use an SVN >> checkout from about 6 hours ago at latest: >> >> http://llvm.org/bugs/show_bug.cgi?id=16363 >> >> Hilariously, this bug was tripped on primitive's Data.Primitive.Types >> module due to some CPP weirdness. But even with a proper bugfix and no >> segfault, it still fails to correctly parse this same module with the >> same CPP declarations. I'm fairly certain this is another bug in >> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately >> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But >> it will *probably* work if we just get rid of the CPP tomfoolery in >> primitive. I'll be testing it in the next few days to see if we can >> get 3.3 supported. (I'm sort of kicking myself in the head for not >> doing this a week or two ago...) >> >> Anyway, there are some rough edges but it should be in shape for 7.8 I >> hope. It should be especially welcome for Mac users. (I'm also hoping >> modern Macs could even go all-clang-all-the-time if my fix for #7602 >> can go in soon...) >> >> PS. If you use ASSERT, I just fixed a lot of instances of using that >> macro, involving whitespace between the name and arguments (commit >> d8ee2b.) Clang does not forgive you for this. Should I note this >> anywhere for the future in the wiki or something? >> >> -- >> Regards, >> Austin - PGP: 4096R/0x91384671 >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin - PGP: 4096R/0x91384671

5 6

Who uses Travis CI and can help write a cookbook for those guys?
by Ryan Newton 28 Jun '13

28 Jun '13

The Travis folks have decided they want to support Haskell better (multiple compiler versions): https://github.com/travis-ci/travis-ci/issues/882#issuecomment-20165378 (Yay!) They're asking for someone to help them up with setup scripts. They mention their cookbook collection here: https://github.com/travis-ci/travis-cookbooks In that thread above, I pasted our little script that fetches and installs multiple GHC versions, but I have little experiences with cloud technologies & VMs. Can someone jump in and help push this forward? As a community I'm sure it would be great to get a higher percentage of Hackage packages using simple, hosted continuous testing... I'd personally like to replace my Jenkins install if they can get the necessary GHC versions in there. Best, -Ryan

1 0

Repeated variables in type family instances
by Richard Eisenberg 26 Jun '13

26 Jun '13

(Sorry for the re-send - got the wrong subject line last time.) Hello all, It's come to my attention that there is a tiny lurking potential hole in GHC's type safety around type families in the presence of UndecidableInstances. Consider the following: > type family F a b > type instance F x x = Int > type instance F [x] x = Bool > > type family G > type family G = [G] This declarations are all valid in GHC 7.6.3. However, depending on the reduction strategy used, it is possible to reduce `F G G` to either Int or Bool. I haven't been able to get this problem to cause a seg-fault in practice, but I think that's more due to type families' strictness than anything more fundamental. Thus, we need to do something about it. I have written a proposal on the GHC wiki at http://hackage.haskell.org/trac/ghc/wiki/NewAxioms/Nonlinearity It proposes a change to the syntax for branched instances (a new form of type family instance that allows for ordered matching), but as those haven't yet been officially released (only available in HEAD), I'm not too worried about it. There are two changes, though, that break code that compiles in released versions of GHC: --- 1) Type family instances like the two for F, above, would no longer be accepted. In particular, the overlap check for unbranched (regular standalone instances like we've had for years) would now check for overlap if all variables were distinct. (This freshening of variables is called 'linearization'.) Thus, the check for F would look at `F x y` and `F [x] y`, which clearly overlap and would be conflicting. 2) Coincident overlap between unbranched instances would now be prohibited. In the new version of GHC, these uses of coincident overlap would have to be grouped in a branched instance. This would mean that all equations that participate in coincident overlap would have be defined in the same module. Cross-module uses of coincident overlap may be hard to refactor. --- Breaking change #1 is quite necessary, as that's the part that closes the hole in the type system. Breaking change #2 is strongly encouraged by the fix to #1, as the right-hand side of an instance is ill-defined after the left-hand side is linearized. It is conceivable that there is some way to recover coincident overlap on unbranched instances, but it's not obvious at the moment. Note that this proposal does not contain a migration path surrounding coincident overlap. In GHC <= 7.6.x, branched instances don't exist and we have coincident overlap among unbranched instances; and in GHC >= 7.8.x, we will prohibit coincident overlap except within branched instances. We (Simon PJ and I) think that this shouldn't be too big of a problem, but please do shout if it would affect you. Please let me know what you think about this proposal! Thanks, Richard

3 10

Type families causing the compiler to hang on recompilation
by Jeroen Weijers 21 Jun '13

21 Jun '13

Hello, I am having a problem with (re)compiling some code I have. I have two modules A and B. In A I have some classes and instances and B uses this. When I try to compile B (with cabal or ghc --make) the first time everything works. When I now modify B (add a space) B is recompiled but the compiler hangs and doesn't seems to be doing anything. I have tested the problem with GHC (x86_64) 7.6.2. 7.6.3 and HEAD. It seems to be very similar to a problem I had earlier: http://hackage.haskell.org/trac/ghc/ticket/7321 but this time there are no GADTs involved. The code of module A (clutter that doesn't contribute to the problem has been removed): > {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE TypeFamilies, TypeOperators, ScopedTypeVariables #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE DataKinds, PolyKinds #-} > > module A where > > import GHC.Generics > > class QA a where > type QRep a > type QRep a = QRep (GRep (Rep a)) > > instance QA () where > type QRep () = () > > -- Kind-polymorphic proxies; > data Pr (a :: k) = Pr > > class (QA (GRep f)) => CaseOf (f :: * -> *) where > type Alg f r k :: * > type GRep f :: * > > -- Only used for the product structure > class QA (ProdRep f) => CaseOfProd (f :: * -> *) where > type ProdAlg f r :: * > type ProdRep f :: * The code of module B: > module B where > import qualified A Given that the code type checks (and if I do not recompile and make an executable directly it actually works) I think this is a bug that might be similar to the bug mentioned in ticket 7321. Does anybody recognise the problem? Should I create a ticket? Cheers, Jeroen Weijers

2 2