August 2013 - ghc-devs

Need to pull Cabal revs from upstream repos over to GHC ones?
by Ryan Newton 03 Aug '13

03 Aug '13

Hi Richard, I think your commit "Update to Cabal to allow RoleAnnotations" needs one more fix that goes along with it. It looks like revision 5fa5c41cd9d2c9b4b543312af6919fe3d8588654 (at depth 4297) is currently pointed to by GHC's Cabal submodule. But those newer commits need to be pushed over to the repo here: http://darcs.haskell.org/libraries/Cabal.git/ Otherwise fresh GHC checkouts have problems right now. -Ryan

2 1

Unit-testing of GHC code
by Jan Stolarek 02 Aug '13

02 Aug '13

I spent whole day looking for a bug that lurks somewhere in my code, but I know I could find it in 2-3 hours if I only could write unit tests for my code. So the question is: how can I write HUnit and QuickCheck (and maybe SmallCheck) tests for GHC and possibly make them a part of testsuite? Janek

3 5

Newtype wrappers
by Simon Peyton-Jones 02 Aug '13

02 Aug '13

Joachim I was talking to Stepanie about newtype wrappers, and realised that a) there are two very different ways to use type classes to implement the feature, one good and one bad b) the one I thought we were using is the Bad One c) the one on the wiki page is sketched in far too little detail but is the Good One http://ghc.haskell.org/trac/ghc/wiki/NewtypeWrappers Also, there's an interaction with "roles" which Richard is on the point of committing. Below are some detailed notes. Before too long, could you refresh the wiki page to: * demote rejected ideas * explain the accepted plan in more detail * discuss implementation aspects Thanks Simon Bad version ~~~~~~~~~~~ class NT a b rep :: NT a b => a -> b wrap :: NT a b => b -> a Then for each newtype newtype Age = Int we generate axiom axAge :: Age ~ Int instance NT Age Int and for data types data (a,b) = (a,b) we generate instance (NT a a', NT b b') => NT (a,b) (a',b') Internally (NT a b) is implemented as a simple boxing of a representational equality: data NT a b = MkNT (a ~#R b) There are many problems here - It's tiresome for the programmer to remember whether to use rep or wrap - Many levels of newtype would require repeated application of rep (or wrap). But if I say (rep (rep x)) I immediately get ambiguity, unless I also supply a type sig for each intermediate level. Good version (this may be what you are doing already) ~~~~~~~~~~~~ class NT a b ntCast :: NT a b => a -> b Notice only one ntCast, which will work both ways. Then for each newtype newtype Age = Int we generate axiom axAge :: Age ~ Int instance NT Int b => NT Age b instance NT a Int => NT b Age Notice *two* instances For data types, same as before data (a,b) = (a,b) we generate instance (NT a a', NT b b') => NT (a,b) (a',b') And we have instance NT a a. Now try this f :: (Age, Bool, Int) -> (Int, Bool, Age) f x = ntCast x >From the ntCast we get the wanted constraint NT (Age,Bool,Int) (Int,Bool,Age) Then we simplify as follows NT (Age,Bool,Int) (Int,Bool,Age) ---> by instance decl for (,,) NT Age Int, NT Bool Bool, NT Int Age ---> by instance NT a a, solves NT Bool Bool NT Age Int, NT Int Age ---> by instance NT Int a => NT Age a NT Int Int, NT Int Age ---> by instance NT a a, solves NT Int Int NT Int Age ...and so on... In effect, we normalise both arguments of the NT independently until they match (are equal, or have an outermost list). This will even do a good job of newtype Moo = MkMoo Age f :: Moo -> Age f x = ntCast x Try it.. it'll normalise the (NT Moo Age) to (NT Int Int), so the coercion we ultimately build wil take x down to Int, then back up to Age. But that's fine... the coercion optimiser will remove the intermediate steps. This has lots of advantages: - No need to remember directions; ntCast does the job in either direction or both - No need for multiple levels of unwrapping... and hence no ambiguity for the intermediate steps. A note about roles ~~~~~~~~~~~~~~~~~~ We are very keen that if we declare data Map key val = [(key,val)] where the keys are kept ordered, then we do NOT want to allow a cast from (Map Int val) to (Map Age val) We were thinking about exercising this control by saying, in a standalone deriving clause deriving NT v1 v2 => NT (Map k v1) (Map k v2) But another, and more robust, way to express the fact that we should not allow you to cast (Map Int val) to (Map Age val) is to give Map the rules p Map key@Nominal val@Representational in Richard's new system (about to be committed). This gives Map's first argument a more restrictive role than role inference would give it. And for good reason! If we had class C k where foo :: Map k Int -> Bool then we would NOT want to allow newtype Age = MkAge Int deriving( C ) And the thing that now prevents us doing that 'deriving( C )' is precisely the more restrictive role on Map. So, our proposal is: for every data T a = ... deriving( NT ) we get the lifting instance instance NT a b => NT (T a) (T b) whose shape is controlled by T's argument roles. We probably want to be able to say -XAutoDeriveNT, like -XAutoDeriveTypeable.

1 0

ghc primop correctness and compile time constants, maybe a type operator for enforced Constantness?
by Carter Schonwald 02 Aug '13

02 Aug '13

Hey all, a number of primops GHC has gained in the past year, prefetch and family, as well as further primops that people (such as myself) hope to add require certain arguments be known constant values at compile time for code gen to work correctly. I detail the problem a little bit further on this ghc trac ticket : http://ghc.haskell.org/trac/ghc/ticket/8107 but the punchline is, a number of valuable SIMD, memory, and concurrent memory model primops that are worth adding to GHC and making first class operations, really require certain arguments to be compile time constant to work correctly. Accordingly, from the perspective of making those operations *truly* first class, augmenting the haskell type system to have a way of expressing "this argument must be a known value at compile time" that doesn't require template haskell shenanigans might be really valuable. thoughts all? note that for some of these arguments that need to be compile time constants, llvm et al will generate different machine code depending on the argument! (llvm doesn't even have the ability to express this invariant in its current API / data model, it just checks it when it tries to compile the code) cheers -Carter

1 0

Mentoring for implementing #8004
by David Luposchainsky 01 Aug '13

01 Aug '13

Hey Devs, I haven't worked on GHC before, so I'm having trouble finding an entry point to implementing the AMP warnings (#8004). I only have a rough working knowledge of GHC's inner workings, but it would be a shame if the ticket wasn't resolved until the 7.8 deadline (which is somewhere in September if I remember it right). My last approach was grepping through the source for "DEPRECATED" and seeing whether there would be an appropriate place for these warnings there, but that wasn't very fruitful. Long story short: can anyone point me in the right direction? I assume the right place to look is somewhere in the typechecker where there's a type class environment, and that's as far as I've come. (It's hard to understand thousands of lines when you're not even sure you're in the right place ...) Greetings, David

3 2