- ghc-devs - Haskell.org

Polymorphism over unboxed tuples
by Ryan Scott 25 Mar '17

25 Mar '17

Section 4.2 of the paper Levity Polymorphism [1] makes a bold claim about polymorphism for unboxed tuples: Note that this format respects the computational irrelevance of nesting of unboxed tuples. For example, these three types all have the same kind, here written PFP for short: type PFP = TYPE '[PtrRep, FloatRep, PtrRep] (# Int, (# Float#, Bool #) #) :: PFP (# Int, Float#, Bool #) :: PFP (# (# Int, (# #) #), Float#, Bool #) :: PFP But in GHC, that isn't the case! Here's proof of it from a recent GHCi session: GHCi, version 8.3.20170322: http://www.haskell.org/ghc/ :? for help λ> :set -XUnboxedTuples -XMagicHash λ> import GHC.Exts λ> :kind (# Int, (# Float#, Bool #) #) (# Int, (# Float#, Bool #) #) :: TYPE ('TupleRep '['LiftedRep, 'TupleRep '['FloatRep, 'LiftedRep]]) λ> :kind (# Int, Float#, Bool #) (# Int, Float#, Bool #) :: TYPE ('TupleRep '['LiftedRep, 'FloatRep, 'LiftedRep]) λ> :kind (# (# Int, (# #) #), Float#, Bool #) (# (# Int, (# #) #), Float#, Bool #) :: TYPE ('TupleRep '['TupleRep '['LiftedRep, 'TupleRep '[]], 'FloatRep, 'LiftedRep]) As you can see, each of these different nestings of unboxed tuples yields different kinds, so they most certainly do *not* uphold the property claimed in the paper. Is this a bug? Or is there some reason that GHC implemented it differently? Ryan S. ----- [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/levity-…

3 3

Slow validate failures
by Ömer Sinan Ağacan 24 Mar '17

24 Mar '17

Hi all, I have a patch that effects profiling code and I realized neither `./validate --fast` nor `./validate` test the "prof" way so I tried `./validate --slow`. I saw that even on a clean branch I get 250 unexpected failures and 6 unexpected passes. I had a quick look at logs. Most of the failures seem to be in these formats: - Compile failed (exit code 1) errors were: T6005a.hs:1:1: fatal: Cannot load -prof objects when GHC is built with -dynamic To fix this, either: (1) Use -fexternal-interpreter, or (2) Build the program twice: once with -dynamic, and then with -prof using -osuf to set a different object file suffix. - Compile failed (exit code 1) errors were: T5984_Lib.hs:3:8: error: Could not find module ‘Prelude’ Perhaps you haven't installed the "p_dyn" libraries for package ‘base-4.10.0.0’? Use -v to see a list of the files searched for. T5984_Lib.hs:5:1: error: Could not find module ‘Language.Haskell.TH’ Perhaps you haven't installed the "p_dyn" libraries for package ‘template-haskell-2.12.0.0’? Use -v to see a list of the files searched for. But there are also some serious-looking failures, like =====> hpc_fork(hpc) 5717 of 5834 [6, 245, 0] ... +++ "/tmp/ghctest-yrj0el9g/test spaces/../../libraries/ghc-compact/tests/compact_share.run/compact_share.run.stdout.normalised" 2017-03-24 00:38:02.486282332 +0300 @@ -1,4 +1,4 @@ 275599 -3801088 +6291456 275599 -2228224 +3506176 So it seems at this point there's basically no realiable way to test profiling changes. I was wondering if someone here know anything about these. If anyone's interested, I pushed test output of `./validate --slow` here: (9.2M file) https://gist.githubusercontent.com/osa1/7cbcc8303f1e213a10accf0bcd9b5ab2/ra… Ömer

1 0

FYI: removing `fibon`
by Michal Terepeta 22 Mar '17

22 Mar '17

Hi all, I wanted to remove `fibon` (from `nofib`) - it's broken, abandoned upstream (no commits in 5 years) and I'm not aware of anyone using it or working on it. At this point I don't think it makes sense to try to revive it - I'd prefer putting the time/effort into getting a few new benchmarks. There were already discussions about removing it in https://ghc.haskell.org/trac/ghc/ticket/11501 If someone is actually working on getting it to work again, please shout! Thanks, Michal PS. I've tried uploading the patch to Phab, but I think it's just too large (arc is crashing). So I've uploaded it to github: https://github.com/michalt/nofib/tree/fibon

2 2

Re: DeriveFoldable treatment of tuples is surprising
by Ryan Scott 22 Mar '17

22 Mar '17

I believe what Sven was saying is not that the Foldable instance for tuples are given "special treatment" (which is arguably an orthogonal discussion), but rather that -XDeriveFoldable special-cases tuples, which is certainly true. As Edward noted, there is one possible justification for this behavior w.r.t. things like newtype V3 a = V3 (a, a, a) deriving Foldable. But to be honest, I find this justification tenuous at best, given the confusion it causes when explaining how DeriveFunctor/DeriveFoldable/DeriveTraversable work to newcomers. Removing this special case would not only be simple, but it would also lead to a more consistent story overall. I would be curious to know how much code in the wild is actually taking advantage of a trick like newtype V3 a = V3 (a, a, a) deriving Foldable. If the breakage isn't terrible, then I propose we just rip off this wart. (This is basically a rehash of the thoughts I left at https://ghc.haskell.org/trac/ghc/ticket/13465#comment:3) Ryan S.

2 1

Re: DeriveFoldable treatment of tuples is surprising
by David Feuer 22 Mar '17

22 Mar '17

The point is that there are two reasonable ways to do it, and the deriving mechanism, as a rule, does not make choices between reasonable alternatives. On Tue, Mar 21, 2017 at 5:05 PM, Jake McArthur <jake.mcarthur(a)gmail.com> wrote: > I think it's a question of what one considers consistent. Is it more > consistent to treat tuples as transparent and consider every component with > type `a`, or is it more consistent to treat tuples as opaque and reuse the > existing Foldable instance for tuples even if it might cause a compile time > error? > > > On Tue, Mar 21, 2017, 4:34 PM David Feuer <david.feuer(a)gmail.com> wrote: >> >> This seems much too weird: >> >> *> :set -XDeriveFoldable >> *> data Foo a = Foo ((a,a),a) deriving Foldable >> *> length ((1,1),1) >> 1 >> *> length $ Foo ((1,1),1) >> 3 >> >> I've opened Trac #13465 [*] for this. As I write there, I think the >> right thing is to refuse to derive Foldable for a type whose Foldable >> instance would currently fold over components of a tuple other than >> the last one. >> >> I could go either way on Traversable instances. One could argue that >> since all relevant components *must* be traversed, we should just go >> ahead and do that. Or one could argue that we should be consistent >> with Foldable and refuse to derive it. >> >> What do you all think? >> >> [*] https://ghc.haskell.org/trac/ghc/ticket/13465 >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

5 4

DeriveFoldable treatment of tuples is surprising
by David Feuer 21 Mar '17

21 Mar '17

This seems much too weird: *> :set -XDeriveFoldable *> data Foo a = Foo ((a,a),a) deriving Foldable *> length ((1,1),1) 1 *> length $ Foo ((1,1),1) 3 I've opened Trac #13465 [*] for this. As I write there, I think the right thing is to refuse to derive Foldable for a type whose Foldable instance would currently fold over components of a tuple other than the last one. I could go either way on Traversable instances. One could argue that since all relevant components *must* be traversed, we should just go ahead and do that. Or one could argue that we should be consistent with Foldable and refuse to derive it. What do you all think? [*] https://ghc.haskell.org/trac/ghc/ticket/13465

1 0

Why are there no Show instances for internal types
by Tom Sydney Kerckhove 20 Mar '17

20 Mar '17

Dear GHC Devs, I am trying to use GHC as a library but I'm having a lot of trouble with understanding what everything means. Up to now, I have been able to figure out what to do by reading the sources, but it ocured to me that much of my struggles could have been mitigated if the relevant types had Show instances. I am specifically talking about the types concerning type checking. TypecheckedModule and everything below that. I am aware that most of the types have an Outputable instance, but there are two problems with that: - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace) - These instances are not intended to show the internal structure of a value, but rather a 'human readable' representation of a value. My questions for you: - Is there a reason that there are no derived 'Show' instances for most types? - Would you accept a diff that adds these? Thank you for your time. -- Tom Sydney Kerckhove

8 13

A possible bug in ghc documentation
by yi lu 20 Mar '17

20 Mar '17

Hi all, Sorry to bother. I'm not sure if this is the right place to post this, but I find a possible bug in ghc documentation. http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/flags.html#la… ^In 7.6.12, -XDeriveGeneric <http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.…> appears twice. If it is a bug, please fix. Thanks. Yi

2 1

PSA: perf.haskell.org/ghc temporarily out of order
by Joachim Breitner 20 Mar '17

20 Mar '17

Hi, a recent change to nofib (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e8ac26d4dfe3…) broke the perf.haskell.org builder, so we won’t be getting perf warnings until that is fixed. I hope that once its up we will not be faced with a large number of performance changes that we will have to track down. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

3 7

Stat too good
by Simon Peyton Jones 19 Mar '17

19 Mar '17

Ben, I still get these four stat-too-good "failures" on 64-bit Linux. Unexpected stat failures: /tmp/ghctest-ca0gfq/test spaces/./perf/compiler/T13035.run T13035 [stat too good] (normal) /tmp/ghctest-ca0gfq/test spaces/./perf/compiler/T12425.run T12425 [stat too good] (optasm) /tmp/ghctest-ca0gfq/test spaces/./perf/compiler/T1969.run T1969 [stat too good] (normal) /tmp/ghctest-ca0gfq/test spaces/./perf/compiler/T9233.run T9233 [stat too good] (normal) Don't you? Simon

3 2