July 2013 - ghc-devs - Haskell.org

Restrictions on polytypes with type families
by Richard Eisenberg 12 Nov '13

12 Nov '13

Hi all, GHC doesn't allow type families to be used with polytypes: 1) The right-hand side of a type family instance cannot have a "forall". 2) A type family cannot be applied to a type containing a "forall". 3) A pattern in a type family instance is (oddly) allowed to contain "forall", but this is silly because of (2). Do these restrictions have known reasons for their existence? Or, are there any that are restricted because someone needs to think hard before lifting it, and no one has yet done that thinking? I know, for example, that the unify function in types/Unify.lhs will have to be completed to work with foralls, but this doesn't seem hard. I've run into two separate cases where I've hit this restriction, so this isn't just idle thought. Thanks, Richard

8 15

HEAD build fails on OS X
by Andreas Voellmy 27 Aug '13

27 Aug '13

I got a fresh copy of HEAD today, and the build failed. The failing command is: $ cd libraries && sh gen_contents_index --intree haddock: internal error: /Users/andreas/repos/temp-ghc-2/ghc-build/inplace/lib/html/Ocean.std-theme/hslogo-16.png: copyFile: does not exist (No such file or directory) I have not yet had time to look into this, but hopefully someone knows what happened here. -Andi

7 17

how to checkout proper submodules
by Kazu Yamamoto 22 Aug '13

22 Aug '13

Hi, Andreas and I found that the new IO manager is not working properly in the current GHC head. I'm sure that it worked well at least on May 7. We need to narrow the range of commits, so I did: % git checkout bb2795db36b36966697c228315ae20767c4a8753 % git submodule update But this does not checkout proper submodules. For instance, libraries/base has newer commits. And of cource, building fails. Please tell us how to checkout proper submodules against a specific GHC tree. --Kazu

21 43

Two Hoopl questions
by Jan Stolarek 13 Aug '13

13 Aug '13

I have two questions about using Hoopl: 1) I'm debugging some Hoopl transformations that often fall into an infinite loop. Probably the easiest way to find the cause would be to allow only a limited number of iterations and then examining the rewritten output. I think that optimization fuel was designed exactly with this scenario in mind, but Compiler.Hoopl module in hoopl library does not re-export functions needed to use Fuel (e.g. runWithFuel). Why are these functions hidden? Is there another interface for using fuel? 2) In my algorithm I need to initialize all of the blocks in a graph with bottom element of a lattice, except for the entry block, which needs some other initial values. I've written something like this: cmmCopyPropagation dflags graph = do let entry_blk = g_entry graph g' <- dataflowPassFwd graph [(entry_blk, (Top , Top))] $ analRewFwd cpLattice cpTransfer cpRewrite return . fst $ g' cpLattice = DataflowLattice "copy propagation" (Bottom, Bottom) cpJoin However, it seems that Bottom values passed to cpLattice are ignored - I could replace them with `undefined` and the code would still run without causing an error. Is there something obviously wrong in the way I pass initial fact values to dataflowPassFwd, or should I look for the problem in other parts of my code? Janek

4 15

Hoopl 3.9 not on hackage
by Thomas Schilling 13 Aug '13

13 Aug '13

I just noticed that the latest version of hoopl (shipped with 7.6.3) is not on Hackage. Is there a reason for this (other than oversight)? / Thomas

4 4

Proposal: provide cas and barriers symbols even without -threaded
by Ryan Newton 12 Aug '13

12 Aug '13

The "atomic-primops" library depends on symbols such as store_load_barrier and "cas", which are defined in SMP.h. Thus the result is that if the program is linked WITHOUT "-threaded", the user gets a linker error about undefined symbols. The specific place it's used is in the 'foreign "C"' bits of this .cmm code: https://github.com/rrnewton/haskell-lockfree-queue/blob/87e63b21b2a6c375e93… I'm trying to explore hacks that will enable me to pull in those functions during compile time, without duplicating a whole bunch of code from the RTS. But it's a fragile business. It seems to me that some of these routines have general utility. In future versions of GHC, could we consider linking in those routines irrespective of "-threaded"? -Ryan

4 30

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

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