- ghc-devs - Haskell.org

Control.Exception.assert vs HsVersions.h's ASSERT?
by RodLogic 11 Nov '14

11 Nov '14

Having spent a bit of time staring at GHC's sources, I noticed that there are around 140 modules using a set of C macros for assertions, namely: ASSERT > ASSERT2 > MASSERT > MASSERT2 > ASSERTM > ASSERTM2 However, I see that Control.Exception already provides a first class Haskell assertion function: assert :: Bool -> a -> a that is turned off automatically when optimizations are turned on, and provides an error containing the filename and line number, which was why I thought the above macros existed and were still in use. My question is: is there any reason to keep using these macros instead of *assert*?

1 0

RFC: Concrete syntax for pattern synonym type signatures
by Dr. ERDI Gergo 11 Nov '14

11 Nov '14

Background ---------- As explained on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Staticsemantics the type of a pattern synonym can be fully described with the following pieces of information: * If the pattern synonym is bidirectional * Universially-bound type variables, and required constraints on them * The type of the pattern itself, closed over the universially-bound type variables * Existentially-bound type variables, and the constraints provided by them * The types of the arguments, closed over the universially and existentially bound type variables Here's an example showing all of these axes in action: data T a b where MkT :: (Eq a, Ord b, Show c) => a -> (b, b) -> c -> T a b pattern P x y = MkT 5 (y, True) x In this case: * The name of the pattern synonym is `P` * The pattern synonym is bidirectional * The universially-bound tyvars/required constraints are `forall a. Num a` * The type of the pattern is `T a Bool` * The existentially-bound tyvars/provided constraints are `forall c. (Eq a, Ord Bool, Show c)` * The type of the arguments are `c` and `Bool`. The problem, then, is finding a concrete syntax that captures all of this information. This syntax is needed for at least two purposes: * Showing pattern synonym type information in Haddock/GHCi * Pattern synonym type signatures (#8584) Current state of things ----------------------- GHCi 7.8.3 shows the type above as: pattern (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t Bool) Not only does it not show directionality, I think this is very confusing in every other way as well, especially with explicit foralls: pattern forall c. (Eq t, Ord Bool, Show c) => P c Bool :: forall t. Num t => (T t Bool) I am currently working on implementing #8584, which means I need to parse these type signatures. I managed to get the above monstrosity to parse (unambigiously from actual pattern synonym definitions) by throwing in an extra 'type' keyword: pattern type (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t Bool) Request for help ---------------- Surely we can do better than that! So let's come up with a nice syntax for pattern synonym type signatures. It will be used in the pattern synonym type signature annotations of GHC 7.10, and we could also retrofit it into GHC 7.8.4 and its Haddock, so that documentation generated with today's tools will look consistent with code you will be able to enter in tomorrow's version. Bye, Gergo

5 25

RE: [commit: ghc] master: Define list monad operations using comprehensions (4923cea)
by Simon Peyton Jones 11 Nov '14

11 Nov '14

The "Note" doesn't mention one of the main points, which is (if I understand rightly) to improve fusion. Would it be wotth making this point, and giving an example in the Note? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 11 November 2014 07:23 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Define list monad operations using | comprehensions (4923cea) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/4923cea56345060faaf77e4c475e | ac6aa3c77506/ghc | | >--------------------------------------------------------------- | | commit 4923cea56345060faaf77e4c475eac6aa3c77506 | Author: David Feuer <David.Feuer(a)gmail.com> | Date: Tue Nov 11 07:59:34 2014 +0100 | | Define list monad operations using comprehensions | | Define list monad operations using list comprehensions. Code using | monad | operations with lists did not fuse fully. Writing list code with | `do` | notation or `(>>=)` and `(>>)` operations could allocate more than | equivalent code using list comprehensions. | | Define `mapM` directly, instead of using `sequence` and `map`. | This | leads to substantially less allocation in `cryptarithm2`. | | Addresses #9781 | | Reviewed By: ekmett, nomeata | | Differential Revision: https://phabricator.haskell.org/D455 | | | >--------------------------------------------------------------- | | 4923cea56345060faaf77e4c475eac6aa3c77506 | libraries/base/GHC/Base.hs | 51 | +++++++++++++++++++++++++++++++++++++++------- | 1 file changed, 44 insertions(+), 7 deletions(-) | | diff --git a/libraries/base/GHC/Base.hs b/libraries/base/GHC/Base.hs | index 501a6d5..0d20e34 100644 | --- a/libraries/base/GHC/Base.hs | +++ b/libraries/base/GHC/Base.hs | @@ -225,8 +225,32 @@ class Monoid a where | mconcat = foldr mappend mempty | | instance Monoid [a] where | + {-# INLINE mempty #-} | mempty = [] | + {-# INLINE mappend #-} | mappend = (++) | + {-# INLINE mconcat #-} | + mconcat xss = [x | xs <- xss, x <- xs] | +-- See Note: [List comprehensions and inlining] | + | +{- | +Note: [List comprehensions and inlining] | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | +The list monad operations are traditionally described in terms of | concatMap: | + | +xs >>= f = concatMap f xs | + | +Similarly, mconcat for lists is just concat. Here in Base, however, | we | +don't have concatMap, and we'll refrain from adding it here so it | won't | +have to be hidden in imports. Instead, we use GHC's list | comprehension | +desugaring mechanism to define mconcat and the Applicative and Monad | instances for lists. | +We mark them INLINE because the inliner is not generally too keen to | +inline build forms such as the ones these desugar to without our | +insistence. Defining these using list comprehensions instead of | foldr | +has an additional potential benefit, as described in | +compiler/deSugar/DsListComp.lhs: if optimizations needed to make | +foldr/build forms efficient are turned off, we'll get reasonably | efficient translations anyway. | +-} | | instance Monoid b => Monoid (a -> b) where | mempty _ = mempty | @@ -501,7 +525,9 @@ sequence ms = foldr k (return []) ms | -- | @'mapM' f@ is equivalent to @'sequence' . 'map' f@. | mapM :: Monad m => (a -> m b) -> [a] -> m [b] {-# INLINE mapM #-} | -mapM f as = sequence (map f as) | +mapM f as = foldr k (return []) as | + where | + k a r = do { x <- f a; xs <- r; return (x:xs) } | | -- | Promote a function to a monad. | liftM :: (Monad m) => (a1 -> r) -> m a1 -> m r | @@ -667,16 +693,27 @@ instance MonadPlus Maybe | -- The list type | | instance Functor [] where | + {-# INLINE fmap #-} | fmap = map | | +-- See Note: [List comprehensions and inlining] | instance Applicative [] where | - pure = return | - (<*>) = ap | - | -instance Monad [] where | - m >>= k = foldr ((++) . k) [] m | - m >> k = foldr ((++) . (\ _ -> k)) [] m | + {-# INLINE pure #-} | + pure x = [x] | + {-# INLINE (<*>) #-} | + fs <*> xs = [f x | f <- fs, x <- xs] | + {-# INLINE (*>) #-} | + xs *> ys = [y | _ <- xs, y <- ys] | + | +-- See Note: [List comprehensions and inlining] instance Monad [] | +where | + {-# INLINE (>>=) #-} | + xs >>= f = [y | x <- xs, y <- f x] | + {-# INLINE (>>) #-} | + (>>) = (*>) | + {-# INLINE return #-} | return x = [x] | + {-# INLINE fail #-} | fail _ = [] | | instance Alternative [] where | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

RE: [GHC] #9741: Interpreter stack checks are not quite right
by Simon Peyton Jones 11 Nov '14

11 Nov '14

| Oh, and the reason you have the debug RTS in your compiler is because | `-ticky` implies `-debug Interesting. I didn't know that. Is that a good idea? Wouldn't it be better to make them independent? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf | Of GHC | Sent: 06 November 2014 08:37 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #9741: Interpreter stack checks are not quite right | | #9741: Interpreter stack checks are not quite right | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: simonpj | Owner: simonmar | Type: bug | Status: closed | Priority: highest | Milestone: 7.10.1 | Component: Compiler | Version: 7.8.3 | Resolution: fixed | Keywords: | Operating System: | Architecture: | Unknown/Multiple | Unknown/Multiple | Difficulty: Unknown | Type of failure: | Blocked By: | None/Unknown | Related Tickets: | Test Case: | | Blocking: | | Differential Revisions: | | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by simonmar): | | Oh, and the reason you have the debug RTS in your compiler is because | `-ticky` implies `-debug`. Incidentally this is probably slowing down | your builds quite a lot, so you might want to turn it off. | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9741#comment:5> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

2 1

Re: [Msys2-users] Debugging undeterministic segfaults
by David Macek 10 Nov '14

10 Nov '14

On 4. 11. 2014 1:30, Ray Donnelly wrote: > Finally, can anyone else confirm the problem? I'm sorry if I missed it, but I can't find what source version you're using, Gintautas. Release/trunk? -- David Macek

3 15

7.10 STABLE freeze date
by Austin Seipp 10 Nov '14

10 Nov '14

Hi all, After some deliberation, we've decided that the STABLE freeze for 7.10 will happen in approximately two weeks, on November 21st. We're hoping to stick to this date closely, but do read below. This is perhaps a short time to freeze, but right now, we've only got a couple things we're planning on focusing on for the next few weeks. And these are really the major things we're waiting for. See below: - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 These are just: - D155, LLVM 3.5 compatibility, - D396 and D169, DWARF/source code note work. These are mostly in me and Simon's court to do another review round, but I think will be OK to get them in on time. - D168, Partial type signatures. The ball is in Simon's court on this one, but he's had several good rounds of discussion with Thomas etc from what I understand. Based on our discussions earlier this week, I think these all will make it just in time for the freeze. Nota bene: if there is *any* delay, it will be for these, as we picked them as the highest priority in our own views. It is unlikely we will delay any so people can sneak in a few other things. So, if you want something of yours in, you better get me, Simon & Simon, Herbert, etc's attention pronto! That way we'll have time to get it in first. To make things easier, we'll also be pushing the lhs->hs conversion pretty soon so cherry picking/merges are easier, and do some other cleanups. And outside of that, we've still been having a healthy flow of bug fixes falling into the tree, which is great. So if you're just bugfixing, please keep doing so - we'll be pulling bugfixes into the tree continuously. We will also be pulling in submodule/library updates continuously, like we did for the 7.8 branch. Let me know if you have questions, objections, or really really really want something - but I won't be as nice as last time I'm afraid. ;) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

10 12

Question about `validate` workflow
by Iavor Diatchki 10 Nov '14

10 Nov '14

Hello, I was wondering how do other devs `validate` their tree? In particular, I just merged a whole bunch of stuff and am validating things. However, every time something goes wrong (e.g., unused import warning), the whole process starts from the beginning, which is quite time consuming. I am using CPUS=4 ./validate --fast Can I do something, to "validate continue", at least until I get a basic validate to pass? I don't mind redoing everything one final time to make sure things are OK, it is just that it seems wasteful while I am fixing things. -Iavor

5 7

Abstracting over constraints: Can this be implemented in GHC?
by Alexander Berntsen 10 Nov '14

10 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I want to be able to write essentially this function: f :: (a -> d) -> (b, c) -> (d, d) f g (x, y) = (g x, g y) What do we need here for this to work? Well, given 'g :: a -> d', we need 'a' ~ 'b' ~ 'c' from the constraints of 'g'. So let 'g = show', such that 'g :: Show a => a -> String'. We need that forall 'a'. 'Show a'. And from that, forall 'b' and 'c', 'Show b' and 'Show C'. f show (1.2, False) = ("1.2", "False") Another example, let 'g = (>2.0)'. Now 'g :: (Ord a, Fractional a) => a -> Bool'. So we need that forall 'a', 'Ord a, Fractional A'. From this we need that forall 'b' and 'c', 'Ord b, Fractional b', and 'Ord c, Fractional c'. f (>5.0) (15, 6/2) = (True, False) One last example, let 'g = id'. now 'g :: a -> a'. No constraints! f id (x, y) = (x, y) How close can we get to this today? Quite close. But the alternatives all feel emphatically wrong to me. λ :set -XRankNTypes λ :set -XConstraintKinds λ let f :: forall b c d k. (k b, k c) => (forall a. k a => a -> d) -> (b, c) -> (d, d); f g (x, y) = (g x, g y) λ (f :: (Show x, Show y) => (forall a. Show a => a -> d) -> (x, y) -> (d, d)) show (1.2, False) We need to specify k every time we use f. That's dreadful! While a nicer syntax (which is suggested, but I don't think it's being actively worked on right now) would allow us to write (f @Show) show (1.2, False) or similar -- it's still not quite right. (Though an obviously massive improvement over the status quo.) Of course, were we merely concerned with getting the job done, we would write either 'bimap g g', 'g *** g' or '\(x, y) -> (g x, g y)'. The former two may look obscure at first ("hmm, why don't they just use 'join'?"), so the latter might actually be best. But it's The Wrong Thing! At least *I* think so. So what do I want here? I guess kind-level forall for constraints, so that 'f' can infer the constraints on 'b' and 'c' from the constraints on 'a' imposed by 'g'. Is this implementable presently? Ever? :-] CC'ing you, SPJ, because, well, types. Also CC'ing you, ekmett, because you have an interesting library called Constraints, so maybe you have some related insight to offer. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlRbRUoACgkQRtClrXBQc7WYbQD+Icr54KvxNA90SKIzPpp726hI wZF4OUtuTXqyXPlU3UYBAIvg8J5uRX+UfNJKOI3PZubCfkJLuraNiW0EIgGD+hgd =fWFQ -----END PGP SIGNATURE-----

2 2

small `arc` victory -- commit message not changed
by Richard Eisenberg 10 Nov '14

10 Nov '14

I just revised a Phab revision using `arc`, and it all worked swimmingly, doing exactly what I wanted, even though this was non-trivial. I describe the process below, and am happy to add to the Phab wiki page, but wanted to check here first to make sure I wasn't making an invisible dreadful mistake. Here's my story: - I had done a few edits in TcSplice and posted the (boring) revision D359. - Austin and Harbormaster both had good suggestions for me. - I spent a week completing other tasks. - I rebased my WIP branch against master. This worried me about what Phab might think. - I incorporated the suggestions. As is my usual workflow, I then rebased to integrate these changes into my original commits. As previously discussed, I think breaking a patch into separable commits is a Good Thing, and I curate these commits to be reader-friendly as I work. In the process, I de-Phabified my previous commit message, worried I was inviting demons, but determined to proceed. - I then updated my Phab revision with this: arc diff --allow-untracked --head HEAD --update D359 Explanation: --allow-untracked is because I have testsuite garbage floating in my working directory, and I'm never confident enough to modify .gitignore to ignore this garbage. `--head HEAD`, I think, is the magic bit. It specifies the *end* of the commit range to be included in the Phab diff. (The beginning was inferred to be origin/master, but can be specified without flags on the command line.) According to `arc help`, "This [flag] disables many Arcanist/Phabricator features which depend on having access to the working copy." Indeed, it was this warning which made me think `--head` was my friend. Of course, specifying `--head HEAD` on the command line seems redundant, but it still effectively stopped `arc` from touching my commits, thinking that this would break my git-ness. So, `arc` did the best job it could without touching my git information, which is exactly what I wanted. Results: My new code is now viewable and reviewable at D359. Despite all of my rebasing, the diffs are clean. You can even ask for the differences between my two revisions, and Phab does the right thing -- even though there's a week's worth of other commits that were rebased in. I'm sure Harbormaster is hard at work right now checking my changes. Fellow devs can offer nice feedback. And, I have retained control over my git structure. Hooray! Question: Have I done anything wrong here? By "wrong", I mean both in a technical sense (e.g., is Harbormaster now deeply confused?) and in a project-management sense (e.g., would this be a bad pattern for others to follow?). Should I put this workflow on the wiki? If no one tells me otherwise, I plan on using `--head` every time. Thanks, Richard

3 2

unexpected failure for scc001
by Joachim Breitner 10 Nov '14

10 Nov '14

Hi, it seems that adding the oneShot annotation to the interface causes scc001 to fail: Actual prof output differs from expected: --- ./profiling/should_run/scc001.prof.sample 2014-11-02 20:21:03.000000000 +0100 +++ ./profiling/should_run/scc001.prof 2014-11-02 20:46:39.000000000 +0100 @@ -1,28 +1,33 @@ - Fri Oct 14 16:27 2011 Time and Allocation Profiling Report (Final) + Sun Nov 2 20:46 2014 Time and Allocation Profiling Report (Final) scc001 +RTS -hc -p -RTS - total time = 0.00 secs (0 ticks @ 20 ms) - total alloc = 46,020 bytes (excludes profiling overheads) + total time = 0.00 secs (0 ticks @ 1000 us, 1 processor) + total alloc = 51,344 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc -MAIN MAIN 0.0 23.0 -CAF GHC.IO.Encoding.Iconv 0.0 1.3 -CAF GHC.IO.Handle.FD 0.0 74.2 +MAIN MAIN 0.0 1.9 +CAF GHC.IO.Encoding 0.0 5.4 +CAF GHC.Conc.Signal 0.0 1.3 +CAF GHC.IO.Handle.FD 0.0 67.3 +main Main 0.0 22.8 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc -MAIN MAIN 101 0 0.0 23.0 0.0 100.0 - CAF GHC.Show 141 0 0.0 0.3 0.0 0.3 - CAF GHC.IO.Handle.FD 128 0 0.0 74.2 0.0 74.2 - CAF GHC.IO.Encoding.Iconv 120 0 0.0 1.3 0.0 1.3 - CAF GHC.Conc.Signal 110 0 0.0 0.7 0.0 0.7 - CAF Main 107 0 0.0 0.4 0.0 0.4 - (...) Main 206 1 0.0 0.0 0.0 0.0 - h Main 205 1 0.0 0.0 0.0 0.0 - main Main 202 1 0.0 0.0 0.0 0.0 - g Main 204 1 0.0 0.0 0.0 0.0 - f Main 203 1 0.0 0.0 0.0 0.0 +MAIN MAIN 44 0 0.0 1.9 0.0 100.0 + main Main 89 0 0.0 22.8 0.0 22.8 + g Main 91 1 0.0 0.0 0.0 0.0 + f Main 90 1 0.0 0.0 0.0 0.0 + CAF Main 87 0 0.0 0.1 0.0 0.1 + (...) Main 93 1 0.0 0.0 0.0 0.0 + h Main 92 1 0.0 0.0 0.0 0.0 + main Main 88 1 0.0 0.0 0.0 0.0 + CAF GHC.IO.Handle.Text 84 0 0.0 0.2 0.0 0.2 + CAF GHC.IO.Encoding.Iconv 80 0 0.0 0.5 0.0 0.5 + CAF GHC.IO.Handle.FD 79 0 0.0 67.3 0.0 67.3 + CAF GHC.Show 77 0 0.0 0.6 0.0 0.6 + CAF GHC.Conc.Signal 74 0 0.0 1.3 0.0 1.3 + CAF GHC.IO.Encoding 72 0 0.0 5.4 0.0 5.4 *** unexpected failure for scc001(profasm) Now after reading some of the code it seems that the output is normalized considerably before comparing. But I’m not fully sure what is being checked here. So things change: Is that change a regression? An improvement? Or just an a wobble that should not worry me? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1