- ghc-devs - Haskell.org

Extending fold/build fusion
by Akio Takano 05 Sep '14

05 Sep '14

Hi, I have been thinking about how foldl' can be turned into a good consumer, and I came up with something that I thought would work. So I'd like to ask for opinions from the ghc devs: if this idea looks good, if it is a known bad idea, if there is a better way to do it, etc. The main idea is to have an extended version of foldr: -- | A mapping between @a@ and @b@. data Wrap a b = Wrap (a -> b) (b -> a) foldrW :: (forall e. Wrap (f e) (e -> b -> b)) -> (a -> b -> b) -> b -> [a] -> b foldrW (Wrap wrap unwrap) f z0 list0 = wrap go list0 z0 where go = unwrap $ \list z' -> case list of [] -> z' x:xs -> f x $ wrap go xs z' This allows the user to apply an arbitrary "worker-wrapper" transformation to the loop. Using this, foldl' can be defined as newtype Simple b e = Simple { runSimple :: e -> b -> b } foldl' :: (b -> a -> b) -> b -> [a] -> b foldl' f initial xs = foldrW (Wrap wrap unwrap) g id xs initial where wrap (Simple s) e k a = k $ s e a unwrap u = Simple $ \e -> u e id g x next acc = next $! f acc x The wrap and unwrap functions here ensure that foldl' gets compiled into a loop that returns a value of 'b', rather than a function 'b -> b', effectively un-CPS-transforming the loop. I put preliminary code and some more explanation on Github: https://github.com/takano-akio/ww-fusion Thank you, Takano Akio

5 20

Copyright headers etc.
by Alexander Berntsen 04 Sep '14

04 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 We should probably do something about copyright headers. They're all very out of date and basically useless. I suggest just having a CONTRIBUTORS file with one name per line, and pointing to that in the files. But IANAL, and copyright is complicated, so other ideas are welcome. - -- 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/ iF4EAREIAAYFAlQIRnsACgkQRtClrXBQc7XDlAD/TEAkGaXPD3jzTDxOYVlyCSwP RIMvBcKuJqZvX+atIOMA/A4e4yuy5QIy9YR7U50jdZVK63fONkFyXa6iTYwuxTCE =rVWx -----END PGP SIGNATURE-----

2 1

Unique as special boxing type & hidden constructors
by p.k.f.holzenspies＠utwente.nl 04 Sep '14

04 Sep '14

Dear all, I'm working with Alan to instantiate everything for Data.Data, so that we can do better SYB-traversals (which should also help newcomers significantly to get into the GHC code base). Alan's looking at the AST types, I'm looking at the basic types in the compiler. Right now, I'm looking at Unique and two questions come up: > data Unique = MkUnique FastInt 1) As someone already commented: Is there a specific reason (other than history) that this isn't simply a newtype around an Int? If we're boxing anyway, we may as well use the default Int boxing and newtype-coerce to the specific purpose of Unique, no? 2) As a general question for GHC hacking style; what is the reason for hiding the constructors in the first place? I understand about abstraction and there are reasons for hiding, but there's a "public GHC API" and then there are all these modules that people can import at their own peril. Nothing is guaranteed about their consistency from version to version of GHC. I don't really see the point about hiding constructors (getting in the way of automatically deriving things) and then giving extra functions like (in the case of Unique): > getKeyFastInt (MkUnique x) = x > mkUniqueGrimily x = MkUnique (iUnbox x) I would propose to just make Unique a newtype for an Int and making the constructor visible. Regards, Philip

5 16

Can Phabricator be made to understand git better?
by Johan Tibell 04 Sep '14

04 Sep '14

Hi, I have to fight Phab too much because it doesn't understand git or git working conventions very well. For example, the other day I uploaded https://phabricator.haskell.org/D128, built from a single git commit on a feature branch I made on a local feature branch (based on my local master). First, doing that was in itself a bit of a pain. 'arc diff' didn't do the right thing and included some random commit(s) instead of my single commit in my feature branch. Perhaps it tried to diff against origin/master or something, which doesn't make any sense if you know how git is meant to be used (doing that would imply that you have to constantly sync with upstream to create a patch.) I eventually got it to used the right commit by doing 'arc diff <commit id>`. Second, today when I wanted to update my commit to address some review comments I 1) amended my commit in my feature branch and 2) ran 'arc diff', expecting that it would do the right thing. It didn't and now D128 contains a bunch of changes that aren't mine. I don't know where they came from. Is there a way to configure Phab so it works with git established workflows? -- Johan

3 3

PROPOSAL: Make Data.Type.Bool.If polykinded
by Merijn Verstraaten 03 Sep '14

03 Sep '14

Ola! Currently we have: type family If cond tru fls where If True tru fls = tru If False tru fls = fls Unfortunately, this appears to turned into a monomorphicly kinded type family by GHC, which means it’s impossible to do foo :: If cond () (“Condition does not hold” ~ “”) => Foo -> Bar or similar fancy constraints. I hereby propose altering If to: type family If (cond :: Bool) (tru :: k) (fls :: k) :: k where If True tru fls = tru If False tru fls = fls Allowing it to work with kinds other than *. Discussion period: 2 weeks? Seems like a minor change. Cheers, Merijn

2 2

deriving Bits
by Kazu Yamamoto 03 Sep '14

03 Sep '14

Hi, Recently, I found that we can put Bits in "deriving". I checked the GHC manual but it seems to me that this page does not cover Bits: https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/deriving.html Are there any other classes which can be automatically derived and are not listed in this page? If the number of such classes is not large, how about adding them to this page? --Kazu

2 4

wORD_SIZE vs platformWordSize of targetPlatform
by Johan Tibell 02 Sep '14

02 Sep '14

Hi, We seem to have two ways to get the same piece of information. We can get the target (?) word size as wORD_SIZE but there's also the platformWordSize field in the Platform data type, which is held as targetPlatform in DynFlags. Which one should I use? Most code uses wORD_SIZE. -- Johan

2 1

Proposal: run GHC API tests on fast
by Edward Z. Yang 02 Sep '14

02 Sep '14

Currently, most GHC API tests are not run on 'make fast', ostensibly because linking against the GHC API can take a while. I propose that change this, and run GHC API tests by default. Reasons: 1. The GHC API is closely tied a lot of internal structure of GHC, so it's very easy to make a change, track it through the rest of the compiler, but forget to update the tests/documentation. 2. We can boost this into poor man's testable documentation. The idea is to duplicate all GHC API examples in the manual in the test suite, and have a comment on all of the examples asking the developer to update the manual. (Or we could automatically extract the snippets from the manual, but that's work and this I could do in a few minutes.) 3. I don't think running these tests will add that much extra run time to the test suite; certainly interactively the time spent linking is unnoticeable. Let's set a one week discussion period for this proposal. Thanks, Edward

4 9

Re: [Haskell] ANNOUNCE: GHC version 7.8.3
by Bryan O'Sullivan 02 Sep '14

02 Sep '14

On Fri, Jul 11, 2014 at 6:40 AM, Austin Seipp <austin(a)well-typed.com> wrote: > The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.3. > haddock 2.14.3 that ships with it seems to be quite broken. Perhaps it's a bad interaction with cabal, it's hard to say from the outside, but here are some details. Here's the kind of error I get from haddock when I try to use cabal to install a package (primitive, in this case): module ‘primitive-0.5.3.0:Main’ is defined in multiple files: dist/build/tmp-92638/Control/Monad/Primitive.hs dist/build/tmp-92638/Data/Primitive/MachDeps.hs dist/build/tmp-92638/Data/Primitive/Types.hs dist/build/tmp-92638/Data/Primitive/Array.hs dist/build/tmp-92638/Data/Primitive/ByteArray.hs dist/build/tmp-92638/Data/Primitive/Internal/Compat.hs The result is that I have no haddock docs for any packages now :-(

9 17

cons/build and making rules look boring
by David Feuer 01 Sep '14

01 Sep '14

I think I may have figured out at least part of the reason that cons/build gives bad results. I actually ran into a clue when working on scanl. It seems at least part of the problem is that a rule like x : build g = build (\c n -> c x (g c n)) makes (:) look "interesting" to the inliner. Unfortunately, as I discovered after much extreme puzzlement about why rules relating to scanl were affecting things that had nothing to do with scanl, it turns out that making (:) look interesting is really quite bad, and something that we probably never want to happen. As a result, the only ways I see to try to make rules like that work properly are 1. If constructors are *always* best treated as boring, and the inliner knows when's a constructor, make it treat them all as boring. 2. Offer a BORINGRULE annotation to indicate that the rule should not make its LHS "interesting", or 3. (I don't like this option much) Make a special case forcing (:) in particular to be boring. David

3 3