- ghc-devs - Haskell.org

gdb values optimized out
by William Kenyon 04 Aug '13

04 Aug '13

Dear GHC devs, I am having problems using gdb to debug ghci. > ./inplace/bin/ghc-stage2 --interactive Segmentation fault (core dumped) > gdb ./inplace/lib/bin/ghc-stage2 core.1234 Which works fine, but many variables are <optimized out>. GhcDebugged=YES is set in my build.mk. > ./inplace/bin/ghc-stage2 +RTS --info ... Rts Way = rts_thr_debug ... > ./inplace/bin/ghc-stage1 +RTS --info ... Rts Way = rts_debug ... The debug way should make all C and C-- files be compiled with -O0. Which should mean that nothing appears <optimized out> in gdb. What am I missing? Thanks, Will

1 0

sync-all get failing
by Simon Peyton-Jones 03 Aug '13

03 Aug '13

./sync-all get is failing (see below). Any ideas? Simon bash-3.1$ ./sync-all get warning: ghc-tarballs already present; omitting == ghc-tarballs: running git config --local core.ignorecase true error: unknown option `local' usage: git config [options] Config file location --global use global config file --system use system config file -f, --file <FILE> use given config file Action --get get value: name [value-regex] --get-all get all values: key [value-regex] --get-regexp get values for regexp: name-regex [value-regex] --replace-all replace all matching variables: name value [value_regex] --add adds a new variable: name value --unset removes a variable: name [value-regex] --unset-all removes all matches: name [value-regex] --rename-section rename section: old-name new-name --remove-section remove a section: name -l, --list list all -e, --edit opens an editor --get-color <slot> find the color configured: [default] --get-colorbool <slot> find the color setting: [stdout-is-tty] Type --bool value is "true" or "false" --int value is decimal number --bool-or-int value is --bool or --int --path value is a path (file or directory name) Other -z, --null terminate values with NUL byte git failed: 33024 at ./sync-all line 116. == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tarball bash-3.1$

2 2

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

02 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 01 Aug '13

01 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

RE: [commit: ghc] master: Add NegativeLiterals extension (ef73963)
by Simon Peyton-Jones 31 Jul '13

31 Jul '13

Ian, Thanks... but if you have added a new language extension, shouldn't you document it in the user manual? What exactly is the different behaviour seen by the user? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of Ian | Lynagh | Sent: 31 July 2013 20:12 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Add NegativeLiterals extension (ef73963) | | Repository : http://darcs.haskell.org/ghc.git/ | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/ef739635a8c2646112d2a1fa4c871 | 5704aff1f1f | | >--------------------------------------------------------------- | | commit ef739635a8c2646112d2a1fa4c8715704aff1f1f | Author: Ian Lynagh <ian(a)well-typed.com> | Date: Wed Jul 31 18:43:11 2013 +0100 | | Add NegativeLiterals extension | | I'd been meaning to do this for some time, but finally got around to it | due to the overflowing literals warning. With that enabled, we were | getting a warning for | -128 :: Int8 | as that is parsed as | negate (fromInteger 128) | which just happens to do the right thing, as | negate (fromInteger 128) = negate (-128) = -128 | | >--------------------------------------------------------------- | | compiler/main/DynFlags.hs | 2 ++ | compiler/parser/Lexer.x | 17 +++++++++++++---- | compiler/utils/Util.lhs | 2 +- | 3 files changed, 16 insertions(+), 5 deletions(-) | | diff --git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs | index eeb48ba..9a56b50 100644 | --- a/compiler/main/DynFlags.hs | +++ b/compiler/main/DynFlags.hs | @@ -558,6 +558,7 @@ data ExtensionFlag | | Opt_LambdaCase | | Opt_MultiWayIf | | Opt_TypeHoles | + | Opt_NegativeLiterals | | Opt_EmptyCase | deriving (Eq, Enum, Show) | | @@ -2726,6 +2727,7 @@ xFlags = [ | ( "IncoherentInstances", Opt_IncoherentInstances, nop ), | ( "PackageImports", Opt_PackageImports, nop ), | ( "TypeHoles", Opt_TypeHoles, nop ), | + ( "NegativeLiterals", Opt_NegativeLiterals, nop ), | ( "EmptyCase", Opt_EmptyCase, nop ) | ] | | diff --git a/compiler/parser/Lexer.x b/compiler/parser/Lexer.x | index 6871210..11d849a 100644 | --- a/compiler/parser/Lexer.x | +++ b/compiler/parser/Lexer.x | @@ -385,12 +385,16 @@ $tab+ { warn Opt_WarnTabs (text "Tab | character") } | -- when trying to be close to Haskell98 | <0> { | -- Normal integral literals (:: Num a => a, from Integer) | - @decimal { tok_num positive 0 0 decimal } | - 0[oO] @octal { tok_num positive 2 2 octal } | - 0[xX] @hexadecimal { tok_num positive 2 2 hexadecimal } | + @decimal { tok_num positive 0 0 | decimal } | + 0[oO] @octal { tok_num positive 2 2 | octal } | + 0[xX] @hexadecimal { tok_num positive 2 | 2 hexadecimal } | + @negative @decimal / { ifExtension negativeLiteralsEnabled } { | tok_num negative 1 1 decimal } | + @negative 0[oO] @octal / { ifExtension negativeLiteralsEnabled } { | tok_num negative 3 3 octal } | + @negative 0[xX] @hexadecimal / { ifExtension negativeLiteralsEnabled } { | tok_num negative 3 3 hexadecimal } | | -- Normal rational literals (:: Fractional a => a, from Rational) | - @floating_point { strtoken tok_float } | + @floating_point { strtoken tok_float } | + @negative @floating_point / { ifExtension negativeLiteralsEnabled } { | strtoken tok_float } | } | | <0> { | @@ -1870,6 +1874,8 @@ explicitNamespacesBit :: Int | explicitNamespacesBit = 29 | lambdaCaseBit :: Int | lambdaCaseBit = 30 | +negativeLiteralsBit :: Int | +negativeLiteralsBit = 31 | | | always :: Int -> Bool | @@ -1925,6 +1931,8 @@ explicitNamespacesEnabled :: Int -> Bool | explicitNamespacesEnabled flags = testBit flags explicitNamespacesBit | lambdaCaseEnabled :: Int -> Bool | lambdaCaseEnabled flags = testBit flags lambdaCaseBit | +negativeLiteralsEnabled :: Int -> Bool | +negativeLiteralsEnabled flags = testBit flags negativeLiteralsBit | | -- PState for parsing options pragmas | -- | @@ -1988,6 +1996,7 @@ mkPState flags buf loc = | .|. typeLiteralsBit `setBitIf` xopt Opt_DataKinds flags | .|. explicitNamespacesBit `setBitIf` xopt Opt_ExplicitNamespaces | flags | .|. lambdaCaseBit `setBitIf` xopt Opt_LambdaCase | flags | + .|. negativeLiteralsBit `setBitIf` xopt Opt_NegativeLiterals | flags | -- | setBitIf :: Int -> Bool -> Int | b `setBitIf` cond | cond = bit b | diff --git a/compiler/utils/Util.lhs b/compiler/utils/Util.lhs | index e2fd0aa..6d42ce7 100644 | --- a/compiler/utils/Util.lhs | +++ b/compiler/utils/Util.lhs | @@ -1095,7 +1095,7 @@ charToC w = | hashString :: String -> Int32 | hashString = foldl' f golden | where f m c = fromIntegral (ord c) * magic + hashInt32 m | - magic = 0xdeadbeef | + magic = fromIntegral (0xdeadbeef :: Word32) | | golden :: Int32 | golden = 1013904242 -- = round ((sqrt 5 - 1) * 2^32) :: Int32 | | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

RE: Exposing newtype coercions to Haskell
by Simon Peyton-Jones 31 Jul '13

31 Jul '13

(Narrowing to ghc-devs.) Re passing bottoms, read "Equality proofs and deferred type errors". http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ The NT type here is playing the role of (~) in that paper. Just as (~) wraps (~#), so NT will wrap (NT#), and it'll play out exactly in the paper. So I'm not bothered about bottoms. Suppose we have a data type data T a b = T1 (S a b) (R b) where we have in scope ntS :: NT p p' -> NT q q' -> NT (S p q) (S p' q') but R is completely abstract. Now, is it safe to say deriving ntT :: NT a a' -> NT (T a b) (T a' b) Well, our criterion is whether we can write by hand, a function foo :: NT a a' -> T a b -> T a' b Let's try: foo g (T1 s r) = T1 (cast s g1) (cast r g2) where g1 :: NT (S a b) (S a' b) g1 = ntS g refl g2 :: NT (R b) (R b) g2 = refl So the general plan is, for each constructor argument of type ty, see if you can build a suitable NT value (g1, g2 in the above example), using either built-in stuff like refl, or arguments like (g :: NT a a'), or in-scope NT values like ntS. If you CAN do that, then it's ok (internally) to use ordinary coercion lifting, roughly ntT g = T g refl The above per-constructor-arg testing is just to make sure that all the relevant witnesses are in scope, to preserve abstraction. It's not for soundness. (There is some "role" stuff to take account of there, which Richard is working on, but to a first approximation that's it I think.) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell- | users-bounces(a)haskell.org] On Behalf Of Joachim Breitner | Sent: 04 July 2013 14:30 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: Exposing newtype coercions to Haskell | | Hi, | | small update: I generalized the code at | https://github.com/nomeata/nt-coerce/blob/9349dd3/GHC/NT/Plugin.hs | a bit, it is now able to handle to create NT-values for unwarpping | arbitrary newtypes and for lifting across type constructors. It does so | unconditionally, i.e. does _not_ yet check whether the constructors are | in scope and whether the user is allowed to cast the types occurring in | the data constructors. | | So what works is this: | | NT values for newtypes without or with type arguments, and possibly | recursive: | | newtype Age = Age Int deriving Show | ageNT :: NT Age Int | ageNT = deriveThisNT -- temporary syntax for deriving | listNT ... | | newtype MyList a = MyList [a] deriving Show | myListNT :: NT (MyList a) [a] | myListNT = deriveThisNT | | newtype R a = R [R a] deriving Show | rNT :: NT (R a) [R a] | rNT = deriveThisNT | | | NT values for type constructors, replacinge all or some of the type | parameters: | | listNT :: NT a b -> NT [a] [b] | listNT = deriveThisNT | | myListNT' :: NT a b -> NT (MyList a) (MyList b) | myListNT' = deriveThisNT | | data F a b c = F a b c deriving Show | fNT :: NT a a' -> NT (F a b c) (F a' b c) | fNT = deriveThisNT | | | What does not work is creating a NT value between a newtype and its | representation if type arguments change on the way, e.g. | | bar :: NT (MyList Age) [Int] | | but the user can construct that himself: | | bar = myListNT' ageNT `trans` myListNT | | | | The next step would be to add the safeguards about the visibility of | constructors and about the types of data constructor parameters. | Especially the latter is still not clear to me: For example with | | data Foo a = Foo (Bar a) | | is it really sufficient to check whether a "barNT:: NT a b -> NT (Bar a) | (Bar b)" exists? After all, I would not need barNT in the generated | implementation of fooNT, so the user could “provide” this value via | undefined and nobody would notice. | | I get the feeling that already the typing rule for TyConAppCo should | expect coercions between the actual types in the data constructors | rather than just between the type constructor parameters, so that the | implementation barNT would actually have to use fooNT. Maybe that would | simplify the two-equalities-approach. But that is just an uneducated gut | feeling. | | | BTW: Is this still on-topic on glasgow-haskell-users or should I move to | ghc-dev? | | | Greetings, | 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 23

Proposal: Gitolite for repository management
by Austin Seipp 31 Jul '13

31 Jul '13

Hello all, Recently with the new haskell.org server move, a few of us have taken roles of administrating the new server infrastructure including ghc.haskell.org, containing the GHC repositories. (Previously, the GHC repos were on abbot.haskell.org, which was maintained by Galois. The new servers are community managed.) I'm one of these people, so first off if you have any problems, let me know! I should also say Herbert Valerio Riedel has also stepped up to help administrate the GHC Trac instance. He's quite experienced in these sorts of matters, and his help is greatly appreciated. If there's anything wrong in this area, he can also be of help. :) Anyway, the real topic: Recently, we have been discussing the way GHC's repositories are managed, and it's slightly suboptimal for several reasons. We would instead like to deploy Gitolite, a smart git-access wrapper. This will not only solve some annoying issues (like Simon's recent permissions error when pushing to testsuite,) but also make ghc.haskell.org more secure and easier to maintain. We have a proposal with preliminary details up here: http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan Please refer to it for the exact details. But the visible overview for all the active developers will be: * Shell accounts will go away. You'll only have access to the repositories. * Your SSH push URL will change very slightly. * sync-all will probably need to change a bit for the new remotes. This will all need to happen within a small window of downtime. As outlined above, we believe we can pull off a switch with minimal interruption. So on that end, we need to know a few things too. What we'd like to know is: * Does any developer who has shell access to ghc.haskell.org actually *need it*? Outside of administrative tasks, I'm not sure who should and should not have access. At the least, your privileges will be slightly reduced after we're done (since the darcs group won't be needed.) * Who is an active committer? I'm not really sure what to do here, but we can easily transplant all the current users in the 'darcs' group. Alternatively we can establish it for most of the core committers, and add people who commit less frequently on a rolling basis (they can just contact me.) * When should this be done? The downtime window will be small hopefully, and I don't think this would really inconvenience anyone too much if we did it soon, but I feel we should ask. -- Regards, Austin - PGP: 4096R/0x91384671

6 6