RFC: Unpacking sum types

[Johan Tibell]

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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Unpacking sum types

[Dan Doel]

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 not going to work at the
Haskell-implemented-level. Since we're at a lower level, we could just
not seq the things from the opposite constructor, but are there
problems that arise from that? Also of course the !Int will probably
also be unpacked, so such prim types need different handling (fill
with 0, I guess).

--

Also, I guess this is orthogonal, but having primitive, unboxed sums
(analogous to unboxed tuples) would be nice as well. Conceivably they
could be used as part of the specification of unpacked sums, since we
can apparently put unboxed tuples in data types now. I'm not certain
if they would cover all cases, though (like the strictness concerns
above).

-- Dan


On Tue, Sep 1, 2015 at 1:23 PM, Johan Tibell  wrote:
> 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
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: more releases

[Richard Eisenberg]

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

This was the sort of thing I thought could be automated. I'm picturing a system 
where Austin/Ben hits a button and everything whirs to life, creating, testing, 
and posting bindists, with no people involved.

> - Writing releases notes & announcment

Release notes should, theoretically, be updated with the patches. Announcement 
can be automated.

> - Coordinating with the HP release process (which requires separate QA)

I'm sure others will have opinions here, but I guess I was thinking that the HP 
wouldn't be involved. These tiny releases could even be called something like 
"7.10.2 build 18". The HP would get updated only when we go to 7.10.3. Maybe we 
even have a binary compatibility requirement between tiny releases -- no 
interface file changes! Then a user's package library doesn't have to be 
recompiled when updating. In theory, other than the bugfixes, two people with 
different "builds" of GHC should have the same experience.

> - If bundled core-libraries are affected, coordination overhead with package
>   maintainers (unless GHC HQ owned), verifying version bumps (API diff!) and
>   changelogs have been updated accordingly, uploading to Hackage

Any library version change would require a more proper release. Do these 
libraries tend to change during a major release cycle?

> - Uploading and signing packagees to download.haskell.org, and verifying
>   the downloads 

This isn't automated?

> 
> Austin & Ben probably have more to add to this list
> 

I'm sure they do.

Again, I'd be fine if the answer from the community is "it's just not what we 
need". But I wanted to see if there were technical/practical/social reasons why 
this was or wasn't a good idea. If we do think it's a good idea absent those 
reasons, then we can work on addressing those concerns.

Richard

> That said, doing more stable point releases is certainly doable if the
> bugs fixed are critical enough. This is mostly a trade-off between time
> spent on getting GHC HEAD in shape for the next major release (whose
> release-schedules suffer from time delays anyway) vs. maintaining a
> stable branch.
> 
> Cheers,
>  hvr

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

more releases

[Richard Eisenberg]

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 objection I can see is that we would want to make sure that users' 
code would work with the new version. Could the Stackage crew help us with 
this? If they run their nightly build with a release candidate and diff against 
the prior results, we would get a pretty accurate sense of whether the bugfix 
is good. If this test succeeds, why not release? Would it be hard to automate 
the packaging/posting process?

The advantage to more releases is that it gets bugfixes in more hands sooner. 
What are the disadvantages?

Richard

PS: I'm not 100% sold on this idea. But I thought it was interesting enough to 
raise a broader discussion.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Unpacking sum types

[Ryan Newton]

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, but have at look like a normal
type constructor?  For example, the type:

   (Sum# T1 T2 T3)

Where "UnboxedSum" can't be partially applied, and is variable arity.
Likewise, "MkSum#" could be a keyword/syntactic-form:

   (MkSum# 1 3 expr)
  case x of MkSum# 1 3 v -> e

Here "1" and "3" are part of the syntactic form, not expressions.  But it
can probably be handled after parsing and doesn't require the "_n_m"
business.

  -Ryan


On Tue, Sep 1, 2015 at 6:10 PM Johan Tibell  wrote:

> 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
>> 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 not going to work at the
>> Haskell-implemented-level. Since we're at a lower level, we could just
>> not seq the things from the opposite constructor, but are there
>> problems that arise from that? Also of course the !Int will probably
>> also be unpacked, so such prim types need different handling (fill
>> with 0, I guess).
>>
>> --
>>
>> Also, I guess this is orthogonal, but having primitive, unboxed sums
>> (analogous to unboxed tuples) would be nice as well. Conceivably they
>> could be used as part of the specification of unpacked sums, since we
>> can apparently put unboxed tuples in data types now. I'm not certain
>> if they would cover all cases, though (like the strictness concerns
>> above).
>>
>> -- Dan
>>
>>
>> On Tue, Sep 1, 2015 at 1:23 PM, Johan Tibell 
>> wrote:
>> > 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
>> >
>> >
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Unpacking sum types

[Ryan Newton]

>
> 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 avoids the awkwardness of attaching it to a
closing delimiter.  But...  it does still introduce the idea of cutting up
tokens to get numbers out of them, which is kind of hacky.  (There seems to
be a conserved particle of hackiness here that can't be eliminate, but it
doesn't bother me too much.)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Unpacking sum types

[Johan Tibell]

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
> 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 not going to work at the
> Haskell-implemented-level. Since we're at a lower level, we could just
> not seq the things from the opposite constructor, but are there
> problems that arise from that? Also of course the !Int will probably
> also be unpacked, so such prim types need different handling (fill
> with 0, I guess).
>
> --
>
> Also, I guess this is orthogonal, but having primitive, unboxed sums
> (analogous to unboxed tuples) would be nice as well. Conceivably they
> could be used as part of the specification of unpacked sums, since we
> can apparently put unboxed tuples in data types now. I'm not certain
> if they would cover all cases, though (like the strictness concerns
> above).
>
> -- Dan
>
>
> On Tue, Sep 1, 2015 at 1:23 PM, Johan Tibell 
> wrote:
> > 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
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Unpacking sum types

[Joachim Breitner]

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 necessary?

If we just add it to Core, to support UNPACK, then there is no parser
involved anyways, and the pretty-printer may do fancy stuff. (Why not
unicode subscript numbers like ₂ :-))

But we probably want to provide this also on the Haskell level, just
like unboxed products, right? Then we should have a nice syntax.

Personally, I find
(# a | b | c #)
visually more pleasing.

(The disadvantage is that this works only for two or more alternatives,
but the one-alternative-unboxed-union is isomorphic to the one-element
-unboxed-tuple anyways, isn’t it?)

>   Likewise, "MkSum#" could be a keyword/syntactic-form:
> 
>(MkSum# 1 3 expr)
>   case x of MkSum# 1 3 v -> e
> 
> Here "1" and "3" are part of the syntactic form, not expressions.  
> But it can probably be handled after parsing and doesn't require the 
> "_n_m" business.

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.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Niklas Hambüchen]

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 all been mentioned already on the
https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub page you linked.

I do however recommend accepting pull requests via Github.

This is already the case for simple changes: In the past I asked Austin
"can you pull this from my branch on Github called XXX", and it went in
without problems and without me having to use arc locally.

But this process could be more automated:

For Ganeti (cluster manager made by Google, written largely in Haskell)
I built a tool (https://github.com/google/pull-request-mailer) that
listens for pull requests and sends them to the mailing list (Ganeti's
preferred way of accepting patches and doing reviews). We built it
because some people (me included) liked the Github workflow (push
branch, click button) more than `git format-patch`+`git send-email`. You
can see an example at https://github.com/ganeti/ganeti/pull/22.
The tool then replies on Github that discussion of the change please be
held on the mailing list. That has worked so far.
It can also handle force-pushes when a PR gets updated based on
feedback. Writing it and setting it up only took a few days.

I think it wouldn't be too difficult to do the same for GHC: A small
tool that imports Github PRs into Phabricator.

I don't like the arc user experience. It's modeled in the same way as
ReviewBoard, and just pushing a branch is easier in my opinion.

However, Phabricator is quite good as a review tool. Its inability to
review multiple commits is nasty, but I guess that'll be fixed at some
point. If not, such an import tool I suggest could to the squashing for you.

Unfortunately there is currently no open source review tool that can
handle reviewing entire branches AND multiple revisions of such
branches. It's possible to build them though, some companies have
internal review tools that do it and they work extremely well.

I believe that a simple automated import setup could address many of the
points in https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator.

Niklas

On 01/09/15 20:34, Thomas Miedema wrote:
> Hello all,
> 
> my arguments against Phabricator are here:
> https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator.
> 
> Some quotes from #ghc to pique your curiosity (there are some 50 more):
>  * "is arc broken today?"
>  * "arc is a frickin' mystery."
>  * "i have a theory that i've managed to create a revision that phab
> can't handle." 
>  * "Diffs just seem to be too expensive to create ... I can't blame
> contributors for not wanting to do this for every atomic change"
>  * "but seriously, we can't require this for contributing to GHC... the
> entry barrier is already high enough" 
> 
> GitHub has side-by-side diffs
>  nowadays, and
> Travis-CI can run `./validate --fast` comfortably
> .
> 
> *Proposal: accept pull requests from contributors on
> https://github.com/ghc/ghc.*
> 
> Details:
>  * use Travis-CI to validate pull requests.
>  * keep using the Trac issue tracker (contributors are encouraged to put
> a link to their pull-request in the 'Differential Revisions' field).
>  * keep using the Trac wiki.
>  * in discussions on GitHub, use https://ghc.haskell.org/ticket/1234 to
> refer to Trac ticket 1234. The shortcut #1234 only works on Trac itself.
>  * keep pushing to git.haskell.org , where the
> existing Git receive hooks can do their job keeping tabs, trailing
> whitespace and dangling submodule references out, notify Trac and send
> emails. Committers close pull-requests manually, just like they do Trac
> tickets.
>  * keep running Phabricator for as long as necessary.
>  * mention that pull requests are accepted on
> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs.
> 
> My expectation is that the majority of patches will start coming in via
> pull requests, the number of contributions will go up, commits will be
> smaller, and there will be more of them per pull request (contributors
> will be able to put style changes and refactorings into separate
> commits, without jumping through a bunch of hoops).
> 
> Reviewers will get many more emails. Other arguments against GitHub are
> here: https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub.
> 
> I probably missed a few things, so fire away.
> 
> Thanks,
> Thomas
> 
> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Planning for the 7.12 release

[Harry .]

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
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Unpacking sum types

[Joachim Breitner]

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 Tibell 
:
>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
>
>
>
>
>___
>ghc-devs mailing list
>ghc-devs@haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Planning for the 7.12 release

[Herbert Valerio Riedel]

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 will also implement compile-warnings in GHC
7.12 to prepare for the next phases, if not they'll follow with the next
major release after GHC 7.12 (effectively extending/delaying the
migration-plan[1] by one year)


 [1]: https://mail.haskell.org/pipermail/libraries/2015-March/025413.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs