RFC: Unpacking sum types

I have a draft design for unpacking sum types that I'd like some feedback on. In particular feedback both on: * the writing and clarity of the proposal and * the proposal itself. https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes -- Johan ___

Re: RFC: Unpacking sum types

I wonder: are there issues with strict/unpacked fields in the sum type, with regard to the 'fill in stuff' behavior? For example: data C = C1 !Int | C2 ![Int] data D = D1 !Double {-# UNPACK #-} !C Naively we might think: data D' = D1 !Double !Tag !Int ![Int] But this is obviously

Re: more releases

On Sep 1, 2015, at 12:01 AM, Herbert Valerio Riedel wrote: > I'd say mostly organisational overhead which can't be fully automated > (afaik, Ben has already automated large parts but not everything can be): > > - Coordinating with people creating and testing the bindists

more releases

Hi devs, An interesting topic came up over dinner tonight: what if GHC made more releases? As an extreme example, we could release a new point version every time a bug fix gets merged to the stable branch. This may be a terrible idea. But what's stopping us from doing so? The biggest

Re: RFC: Unpacking sum types

Just a small comment about syntax. Why is there an "_n" suffix on the type constructor? Isn't it syntactically evident how many things are in the |# .. | .. #| block? More generally, are the parser changes and the wild new syntax strictly necessary? Could we instead just have a new keyword,

Re: RFC: Unpacking sum types

> > If we expose it on the Haskell level, I find MkSum_1_2# the right thing > to do: It makes it clear that (conceptually) there really is a > constructor of that name, and it is distinct from MkSum_2_2#, and the > user cannot do computation with these indices. > I don't mind MkSum_1_2#, it

Re: RFC: Unpacking sum types

After some discussions with SPJ I've now rewritten the proposal in terms of unboxed sums (which should suffer from the extra seq problem you mention above). On Tue, Sep 1, 2015 at 11:31 AM, Dan Doel wrote: > I wonder: are there issues with strict/unpacked fields in the sum >

Re: RFC: Unpacking sum types

Hi, Am Mittwoch, den 02.09.2015, 01:44 + schrieb Ryan Newton: > Why is there an "_n" suffix on the type constructor? Isn't it > syntactically evident how many things are in the |# .. | .. #| > block? Correct. > More generally, are the parser changes and the wild new syntax > strictly

Re: Proposal: accept pull requests on GitHub

Hi, I would recommend against moving code reviews to Github. I like it and use it all the time for my own projects, but for a large project like GHC, its code reviews are too basic (comments get lost in multi-round reviews), and its customisation an process enforcement is too weak; but that has

RE: Planning for the 7.12 release

Proposal: Make Semigroup as a superclass of Monoid https://mail.haskell.org/pipermail/libraries/2015-April/025590.html ___ ghc-devs mailing list ghc-devs@haskell.org

Re: RFC: Unpacking sum types

Hi, just an idea that crossed my mind: Can we do without the worker/wrapper dance for data constructors if we instead phrase that in terms of pattern synonyms? Maybe that's a refactoring/code consolidation opportunity. Good night, Joachim Am 1. September 2015 10:23:35 PDT, schrieb Johan

Re: Planning for the 7.12 release

On 2015-09-01 at 13:57:17 +0200, Harry . wrote: > Proposal: Make Semigroup as a superclass of Monoid > https://mail.haskell.org/pipermail/libraries/2015-April/025590.html The plan is to (at the very least) move Data.Semigroups and Data.List.NonEmpty to base for GHC 7.12 If we have enough time we