July 2013 - Glasgow-haskell-users

ANNOUNCE: ghci-ng package
by Herbert Valerio Riedel 20 Jul '13

20 Jul '13

Hello GHC HQ, I wanted to inform you that I created the `ghci-ng` package http://hackage.haskell.org/package/ghci-ng-7.6.3.3 which essentially is the ghc/* folder from the GHC source-tree with a ghci-ng.cabal file put in place (and some dummy .h files) to make the interactive-mode GHC front-end compilable w/o requiring the full GHC source-tree. The reason I created ghci-ng was to be able to backport features from GHC HEAD so that Haskell user not living on the bleeding edge (such as Haskell Platform users) don't have to wait for half a year or so till they can use new features[1]. On the other hand, this might also allow to expose new work-in-progress features to users in production environments to play with before those features find their way into a final GHC release, and thus help with developing new GHCi features in a more "agile" way by getting feedback from potential users earlier. So ghci-ng is *not* supposed to replace ghci, but rather provide an testing ground for evaluating new/experimental features which may get merged into upstream GHCi eventually if they prove useful. Please let me know what you think of this. [1]: The killer-feature right now being the new `:complete` command which allows the latest (unreleased) haskell-mode to provide REPL-completion from within the Emacs buffer. Cheers, hvr

1 0

How to fix DatatypeContexts?
by harry 19 Jul '13

19 Jul '13

data Eq a => Pair a = Pair {x::a, y::a} equal :: Pair a -> Bool equal pair = (x pair) == (y pair) This code will fail to compile, even with the deprecated DatatypeContexts extension, because equal must be given the Eq a => constraint, even though this has already been declared on the Pair type. Some of my code is littered with such redundant type constraints (although some of them could be replaced with a redundant pattern match). A proposal to enhance DatatypeContexts (#8026) in this way was rejected as unsound, as some nefarious uses of undefined would break the type system. Is there any way that the type system could be enhanced to avoid this redundancy? -- View this message in context: http://haskell.1045720.n5.nabble.com/How-to-fix-DatatypeContexts-tp5733103.… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

8 15

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