- ghc-devs - Haskell.org

Type-level reasoning ability lost for TypeLits?
by Gabor Greif 03 Jan '14

03 Jan '14

Hi devs, with recent iterations of GHC.TypeLits (HEAD) I am struggling to get something simple working. I have > data Number nat = KnownNat nat => Number !(Proxy nat) and want to write > addNumbers :: Number a -> Number b -> Maybe (Number (a + b)) Unfortunately I cannot find a way to create the necessary KnownNat (a + b) constraint. Declaring the function thus > addNumbers :: KnownNat (a + b) => Number a -> Number b -> Maybe (Number (a + b)) only dodges the problem around. Also I am wondering where the ability to perform a type equality check went. I.e. I cannot find the relevant functionality to obtain > sameNumber :: Number a -> Number b -> Maybe (a :~: b) I guess there should be some TestEquality instance (for Proxy Nat?, is this possible at all), but I cannot find it. Same applies for Symbols. Any hints? Thanks and cheers, Gabor

2 2

Building GHC head with clang on Mavericks
by Kazu Yamamoto 03 Jan '14

03 Jan '14

Hi, As I wrote in the following blog article, I could build GHC head on Mavericks 20 days ago. http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924 But I cannot build it recently: ---- "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db libraries/bootstrapping.conf -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -package array -no-user-package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build -c utils/genprimopcode/dist/build/Lexer.hs -o utils/genprimopcode/dist/build/Lexer.o <built-in>:2:2: Not in scope: `#' make[1]: *** [utils/genprimopcode/dist/build/Lexer.o] Error 1 make[1]: *** Waiting for unfinished jobs.... shift/reduce conflicts: 46 reduce/reduce conflicts: 1 make: *** [all] Error 2 ---- I seems to me that linemarkers generated by GCC(CPP) is not correctly handled when alex is used. Note I can build GHC head on FreeBSD and Linux. I'm using clang with clang-xcode5-wrapper.hs. Any suggestions? --Kazu

5 34

Re: Re: [commit: packages/base] master: Improve error messages for partial functions in Data.Data (d0b74ca) (Gabor Greif)
by Krzysztof Langner 02 Jan '14

02 Jan '14

Hi Gabor, Thank you for the feedback. You are right about spelling. I'll fix it. Regarding refactoring: If I understand you correctly your suggestion is to add new function which will wrap error message so the text will be less redundant. I'm not sure about it. From my experience it is better to leave error messages as simple as possible. Since when using functions in error messages it is possible that this function will fail and then you will get confusing error message (from inside function). So as a rule of thumb I never add another functions inside error processing (except the ones which makes message more meaningful). But that's of course just my point of view. It is also possible that I didn't understand your proposition correctly :-) -- Thanks Krzysztof

2 1

Re: [commit: packages/base] master: Improve error messages for partial functions in Data.Data (d0b74ca)
by Gabor Greif 01 Jan '14

01 Jan '14

On 1/1/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/base > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/d0b74cac0b0ab5371d15b6f73c0e627b4… > >>--------------------------------------------------------------- > > commit d0b74cac0b0ab5371d15b6f73c0e627b41c3a152 > Author: Krzysztof Langner <klangner(a)gmail.com> > Date: Wed Jan 1 14:14:46 2014 +0100 > > Improve error messages for partial functions in Data.Data > > This closes: #5412 Hi Krzysztof, there are typos "an Real" --> "a Real" but this actually your commit begs for a refactoring > "something" `notAsExpected` "a Real" etc. as it would eliminate a bunch of (string) redundancy. Cheers, Gabor > > >>--------------------------------------------------------------- > > d0b74cac0b0ab5371d15b6f73c0e627b41c3a152 > Data/Data.hs | 76 > ++++++++++++++++++++++++++++++++++++++++------------------ > 1 file changed, 53 insertions(+), 23 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder > --ignore-space-at-eol --cc d0b74cac0b0ab5371d15b6f73c0e627b41c3a152 > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

We need a bugfix release for 7.6 or get 7.8 soon to support OS X Mavericks
by Johan Tibell 31 Dec '13

31 Dec '13

Hi all, It's getting more urgent to have a working GHC on OS X Mavericks. 35% [1] of OS X users are now on Mavericks and won't have a working GHC unless they jump through some hoops [2]. If we don't think we can have 7.8 out in the next few days, I think we should consider making a minimal 7.6.x release to make things work on OS X again. 1. https://www.gosquared.com/mavericks/ 2. https://gist.github.com/mzero/7245290 -- Johan

2 1

Common Context transformation for join points
by Joachim Breitner 31 Dec '13

31 Dec '13

Hi all, I just came up with this, and unless I write it down I doubt I’ll be able to fall asleep. The problem I’m trying to solve is the bad interaction of the CPR worker wrapper transformation and join points. Consider, as a running example: f x = let $j n = Just (Int# (n +# 1)) in case x of A -> $j 1 B -> $j 2 C -> Just undefined The join point $j has the important property that in the final code, it can be jumped to, because its result is also the result of f, so no function closure has to be allocated for it. It seems that this is crucial for performance. But now lets do CPR, and just for demonstration, do nested CPR (the effect can also occur with non-nested CPR). Doing w/w we get $wf x = case ( let $w$j n = n +# 1 $j n = Just (Int# ($w$j n)) in case x of A -> $j 1 B -> $j 2 C -> Just undefined ) of Just n -> n f x = Just ($wf x) now we simplify, i.e. move the worker transformation inside, and inline $j’s wrapper. (I hope I am doing this right; but this is what I expect to happen): $wf x = let $w$j n = n+1 in case x of A -> Int# ($w$j 1) B -> Int# ($w$j 2) C -> undefined f x = Just ($wf x) So f’s worker transformation has nicely canceled with the invocations of Just, but it still leaves a "Int#" invocation around $w$j, so we lose the no-let-escape property of it and get worse code in the backend. This will always happen if the join point function gets a richer CPR property than the function that it belongs to, and is the reason for some hacks in the CPR code (i.e. no CPR for locally stuff that returns a sum type... not nice.) I think I have a solution for this. One observation is that these $j-functions are not really functions of their own. For this transformation (and possibly for others), one should try to treat them so that they behave as if they were inlined. So here is the idea: We do not do any w/w for $j at first, on the premise that it is not a proper function of its own. We do w/w for f as before, and simplify as before, ending up with $wf x = let $j n = Just (Int# (n +# 1)) in case x of A -> case $j 1 of Just n -> n B -> case $j 2 of Just n -> n C -> undefined f x = Just ($wf x) so we temporarily broke the property. Now a new simplifier step kicks in: For a let that looks like it was or should be a join point (hand waving here – one could possibly do it for all non-recursive lets, maybe there is even more to gain), we find out for all uses of $j applied to its arity number of arguments, what is the largest common context? where a context is * ·, the trivial context, * case c of ..., where c is a context, and ... does not contain a call to $j, * f c, where c is a context and f does not contain a call to $j, or * c x, where c is a context and f does not contain a call to $j. In particular we do not include code here where $j is part of an alternative of a case. (Casts should ok fine as well, ignoring them for now.) In our example, the context would be "case · of Just n -> n". Once we have found that, I believe it will be always safe and beneficial to replace the body e of $j by c[e], and in the body of the let replace every c[$j args..] by $j args. In our example, we would obtain $wf x = let §j n = case Just (Int# (n +# 1)) of Just n -> n in case x of A -> $j 1 B -> $j 2 C -> undefined f x = Just ($wf x) which then in further steps simplifies to the in all respects ideal code $wf x = let §j n = Int# (n +# 1)) in case x of A -> $j 1 B -> $j 2 C -> undefined f x = Just ($wf x) Implementationwise I figured that this will need two traversals (down and up each) of the let body: Starting from a let binding that looks promising (e.g. one-shot non-recursive lambda), walk down the body until invocations of the right arity are found. Then walk back returning a growing contest, and at case-expressions lub these contexts by taking their common prefix (or suffix, depends on how they are represented :-)). Then decide whether the transformation is useful (i.e. the context is non-trivial), and if so, walk back down to find the $j invocations again, and then walk back, removing the final context while doing so. I believe this would make some let-no-escape-related reluctanceness in the CPR-analysis obsolete, which would be great. And it might be a worthwhile transformation on its own (if it actually does occur), as it reduces code size without any downside (as far as I can see). Now it is likely that I thought of something existing here, or of something that has been tried and found not useful or feasible. If so, please let me know. Good night, 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

2 3

More GND + role inference woes
by Edward Kmett 31 Dec '13

31 Dec '13

Ben Gamari was trying to update my linear package to work with GHC HEAD. Along the way he noted an example of the new GND+role inference machinery failing rather spectacularly. http://hackage.haskell.org/package/linear-1.3/docs/src/Linear-Affine.html#P… Note the number of classes that the current proposal would force us to hand implement. =( -Edward

5 20

whats our timeline for 7.8 release?
by Carter Schonwald 30 Dec '13

30 Dec '13

hey all, many many folks are wondering about when 7.8 is going to hit RC officially. What are the bugs / blockers / etc that are left to deal with? We should at least aim to communicate whats going on instead of leaving folks wondering. -Carter

3 3

Renaming Void#
by Krzysztof Gogolewski 30 Dec '13

30 Dec '13

Hello, Small bikeshedding: I propose to rename recently added Void# (in GHC.Prim) to Unit#, and void# to unit#. As far as I understand, this type is the unboxed equivalent of () (i.e. single-element type) rather than Void (i.e. empty type). The name Void# might be reserved for a type which has completely no inhabitants. Any comments? KG

5 5

Preparing for a review of pattern synonyms
by Dr. ERDI Gergo 29 Dec '13

29 Dec '13

Hi, I believe I've finished implementing version 1 of pattern synonyms (i.e. everything described in #5144, minus the things in #8581, #8582, #8583 and #8584). I've discussed the way forward with SPJ and he suggested because of the cross-cutting nature of the patch, I should wait a reasonably long time (~1 month) after 7.8 is branched off for things to settle, and then formally submit it for review. So my question is, is there anything I can do in the meantime, in preparation for the review? The code is available at https://github.com/gergoerdi/ghc. I've also added some tests to the testsuite (https://github.com/gergoerdi/ghc-testsuite) and updated the wiki pages at https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms and https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation. Thanks, Gergo

5 15