August 2017 - ghc-devs

GHC's module hierarchy
by Simon Peyton Jones 02 Oct '19

02 Oct '19

Dear ghc-devs hsyl20 proposes a radical overhaul of the module structure of GHC itself. He or she suggested it six months ago in https://ghc.haskell.org/trac/ghc/ticket/13009 and has now offered a monster patch https://phabricator.haskell.org/D3647 It's clearly the result of a lot of work, but I was the only one who responded on the original ticket, and it'll affect all of your lives in a very immediate way. So, would you like to * consider the idea * look at the actual re-mapping of modules hsyl20 proposals * express an opinion about whether to go ahead Probably the ticket, rather than Phab, is the best place to comment on the general idea. I'd like to thank hsyl20. GHC's rather flat module structure has grown incrementally over years. But still, there are pros and cons. Simon

2 1

Default options for -threaded
by lonetiger＠gmail.com 04 Jan '19

04 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

Bringing back #ghc IRC logging
by Niklas Hambüchen 25 Oct '17

25 Oct '17

Hi, as you may have noticed, #ghc IRC logging has been broken for months (though the channel topic still says "Logs: http://ircbrowse.net/ghc"). Logs being unavailable is bad because many problems and topics that were googleable before are no longer googleable. We have discussed in the last 2 days on #ghc whether we should just join #ghc with a 0-effort-on-our-side public logging service like botbot.me. This one in particular doesn't have the best UI but I found it to be very googleable, and many open-source projects use it successfully. Is anybody opposed to this? Niklas

4 5

[ANNOUNCE] GHC 8.2.1 release candidate 1
by Ben Gamari 03 Oct '17

03 Oct '17

Hello everyone, The GHC team is very pleased to announce the first candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.1-rc1/ This is the first of a few release candidates leading up the final 8.2.1 release. This release will feature, * A new type-indexed Typeable implementation * The long awaited Backpack * Deriving strategies for disambiguating DeriveAnyClass, GeneralizedNewtypeDeriving, and stock mechanisms * Overloaded record fields * Improved compiler performance * Better code generation through more robust tracking of join points * Compact regions for more efficient garbage collection and serialization * Better support for machines with non-uniform memory architectures * More robust support for levity (e.g. RuntimeRep) polymorphism * A simple interface for streaming eventlog data from live processes * Further refinement of DWARF support Unfortunately there are still a few known issues in this release, including a few compiler panics (#13233, #13509) and a memory leak in the simplifier (#13426) which may adversely affect heap sizes and compilation time for some modules. This memory leak unfortunately made it impossible to provide a 32-bit Windows distribution for this candidate; this will be resolved in -rc2. As always, please let us know if you have difficulty. Thanks to everyone who has contributed to this release! Happy testing, - Ben

5 15

Disabling Travis?
by Joachim Breitner 02 Oct '17

02 Oct '17

Hi, I wasn’t looking for a while I notice that the travis CI build of GHC has not been succeeding for two months, partly because build time exceeded the already much extended limits we have, partly because support for booting with 7.10 was dropped, but the .travis file was not used. A CI system that is not normally succeeding is pretty pointless, and will only confuse people who submit pull requests over GitHub who see failures. So if noone complains now I will soon disable building on Travis. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

3 14

New primitive types?
by Michal Terepeta 26 Sep '17

26 Sep '17

Hi all, I'm working on making it possible to pack constructor fields [1], example: ``` data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32 ``` should only require 4 bytes for unpacked `Float` and 4 bytes for unpacked `Int32`, which on 64-bit arch would take just 1 word (instead of 2 it currently does). The diff to support packing of fields is in review [2], but to really take advantage of it I think we need to introduce new primitive types: - Int{8,16,32}# - Word{8,16,32}# along with some corresponding primops and with some other follow-up changes like extending `PrimRep`. Then we could use them in definitions of `Int{8,16,32}` and `Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`). Does that sound ok with everyone? (just making sure that this makes sense before I invest more time into this :) Thanks, Michal [1] https://ghc.haskell.org/trac/ghc/ticket/13825 [2] https://phabricator.haskell.org/D3809

4 9

Phab: conditional approval
by Richard Eisenberg 14 Sep '17

14 Sep '17

Hi devs, When reviewing a diff on Phab, I can "accept" or "request changes". Sometimes, though, I want to do both: I suggest very minor (e.g., typo) changes, but then when these changes are made, I accept. I'm leery of making the suggestions and saying "accept", because then someone working quickly may merge without noticing the typos. Does Phab have such an option? Thanks, Richard

4 5

Type-level generics
by David Feuer 01 Sep '17

01 Sep '17

I've been thinking for several weeks that it might be useful to offer type-level generics. That is, along with to :: Rep a k -> a from :: a -> Rep a perhaps we should also derive type family To (r :: Rep a x) :: a type family From (v :: a) :: Rep a x This would allow us to use generic programming at the type level For example, we could write a generic ordering family: class OrdK (k :: Type) where type Compare (x :: k) (y :: k) :: Ordering type Compare (x :: k) (y :: k) = GenComp (Rep k ()) (From x) (From y) instance OrdK Nat where type Compare x y = CmpNat x y instance OrdK Symbol where type Compare x y = CmpSymbol x y instance OrdK [a] -- No implementation needed! type family GenComp k (x :: k) (y :: k) :: Ordering where GenComp (M1 i c f p) ('M1 x) ('M1 y) = GenComp (f p) x y GenComp (K1 i c p) ('K1 x) ('K1 y) = Compare x y GenComp ((x :+: y) p) ('L1 m) ('L1 n) = GenComp (x p) m n GenComp ((x :+: y) p) ('R1 m) ('R1 n) = GenComp (y p) m n GenComp ((x :+: y) p) ('L1 _) ('R1 _) = 'LT GenComp ((x :+: y) p) ('R1 _) ('L1 _) = 'GT GenComp ((x :*: y) p) (x1 ':*: y1) (x2 ':*: y2) = PComp (GenComp (x p) x1 x2) (y p) y1 y2 GenComp (U1 p) _ _ = 'EQ GenComp (V1 p) _ _ = 'EQ type family PComp (c :: Ordering) k (x :: k) (y :: k) :: Ordering where PComp 'EQ k x y = GenComp k x y PComp x _ _ _ = x For people who want to play around with the idea, here are the definitions of To and From for lists: To ('M1 ('L1 ('M1 'U1))) = '[] To ('M1 ('R1 ('M1 ('M1 ('K1 x) ':*: 'M1 ('K1 xs))))) = x ': xs From '[] = 'M1 ('L1 ('M1 'U1)) From (x ': xs) = 'M1 ('R1 ('M1 ('M1 ('K1 x) ':*: 'M1 ('K1 xs)))) David

4 4

Re: dll-split
by Ryan Scott 30 Aug '17

30 Aug '17

Thanks for putting so much effort into this work, Tamar! > When I do turn it on, by default you will get a large ~45min hit in compile time. Yikes, that's really bad! Bad enough that I have to wonder: would it be worth including genlib among the other executables that we bundle with GHC? Fortunately, us GHC developers have the foresight to know that we should install genlib, but I imagine less informed Windows users probably won't get the memo and will start to wonder why compilation became so slow all of a sudden. Ryan S.

3 3

dll-split
by lonetiger＠gmail.com 29 Aug '17

29 Aug '17

Hi All, I have just killed off dll-split, this means that you no longer need to maintain a list of modules in GHC.mk. If you’re a non-Windows programmer you can stop reading here, for those that build on Windows: The replacement for dll-split is called gen-dll, and it is able to automatically partition any library we build, so this issue is hopefully solved once and for all. Currently dynamic linking is still turned off as I have a few more patches to upstream. When I do turn it on, by default you will get a large ~45min hit in compile time. This is because dlltool which BFD based is quite slow. To mitigate this gen-dll supports the use of the msys2 project’s genlib tool. This tool finishes in seconds instead of tens of minutes like dlltool. To install it just run pacman -Sy mingw-w64-$(uname -m)-tools-git The wiki pages have been updated accordingly already. If you install this now you won’t notice any difference in build time later. Thanks, Tamar

1 0