From blamario at ciktel.net  Sun Nov  4 15:04:27 2018
From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Sun, 4 Nov 2018 10:04:27 -0500
Subject: Report merged, steps to follow
Message-ID: <8a11390b-fbf2-ead1-7783-082d2b813e91@ciktel.net>

Four weeks having passed since the previous discussion with no 
objections, I have now merged the content of the Haskell Report

from https://github.com/haskell/haskell-report

into https://github.com/haskell/rfcs


     To remind everybody again, the point of this move was to enable 
adding an actionable change to the report to every RFC. From this point 
on, any proposal that passes the full process to becoming accepted can 
update the report by the simple act of getting merged.

     In order to test this process, over a year ago I've picked and 
submitted the least controversial RFC I could find, namely 
https://github.com/haskell/rfcs/pull/17. There has been no objection to 
the proposal. In fact there has been no comment whatsoever, but I 
suppose that's beside the point. So today I have moved the RFC to the 
"Last Call" column (https://github.com/haskell/rfcs/projects/1) as the 
first and only proposal to gain that awesome status.

     It's not at all clear what should happen to the RFC between this 
point and it getting merged, but I'm determined to test drive the 
process with it. This is my plan:

1. I'm going to add update the report with a patch to the report 
content, then

2. wait another two weeks for any objection before

3. moving the proposal from the Last Call to the Ready for Report 
status, then

4. announce that the proposal is Ready for Report and

5. wait another two weeks for the full approval, then finally

6. merge the RFC.


     The only flaw in my cunning plan above is defining what constitutes 
"the full approval". The committee being rather ... disengaged and 
scattered, there is little hope of getting 50% of votes from all its 
members. The criteria of no raised objection, which I've used so far, 
seems much too lax for a full approval. I think the only reasonable fair 
criteria of success would be a public and unanimous approval by at least 
N committee members. I have no idea what N should be, but I know that if 
this test proposal can't garner N approvals, no proposal will ever pass 
the hurdle.

     To make it plain, I suggest we take the number of committee members 
that comment on the test proposal as the maximum bound of N. I do hope 
max(N) > 1.



From carter.schonwald at gmail.com  Sun Nov  4 17:09:20 2018
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 4 Nov 2018 12:09:20 -0500
Subject: Report merged, steps to follow
In-Reply-To: <8a11390b-fbf2-ead1-7783-082d2b813e91@ciktel.net>
References: <8a11390b-fbf2-ead1-7783-082d2b813e91@ciktel.net>
Message-ID: <CAHYVw0zcKtYRMavfKiLLb49BwJb=5VY7=_W_GHkKhZDFPis6tg@mail.gmail.com>

sounds good to me, we can always tweak stuff as needed

On Sun, Nov 4, 2018 at 10:04 AM Mario Blažević <blamario at ciktel.net> wrote:

> Four weeks having passed since the previous discussion with no
> objections, I have now merged the content of the Haskell Report
>
> from https://github.com/haskell/haskell-report
>
> into https://github.com/haskell/rfcs
>
>
>      To remind everybody again, the point of this move was to enable
> adding an actionable change to the report to every RFC. From this point
> on, any proposal that passes the full process to becoming accepted can
> update the report by the simple act of getting merged.
>
>      In order to test this process, over a year ago I've picked and
> submitted the least controversial RFC I could find, namely
> https://github.com/haskell/rfcs/pull/17. There has been no objection to
> the proposal. In fact there has been no comment whatsoever, but I
> suppose that's beside the point. So today I have moved the RFC to the
> "Last Call" column (https://github.com/haskell/rfcs/projects/1) as the
> first and only proposal to gain that awesome status.
>
>      It's not at all clear what should happen to the RFC between this
> point and it getting merged, but I'm determined to test drive the
> process with it. This is my plan:
>
> 1. I'm going to add update the report with a patch to the report
> content, then
>
> 2. wait another two weeks for any objection before
>
> 3. moving the proposal from the Last Call to the Ready for Report
> status, then
>
> 4. announce that the proposal is Ready for Report and
>
> 5. wait another two weeks for the full approval, then finally
>
> 6. merge the RFC.
>
>
>      The only flaw in my cunning plan above is defining what constitutes
> "the full approval". The committee being rather ... disengaged and
> scattered, there is little hope of getting 50% of votes from all its
> members. The criteria of no raised objection, which I've used so far,
> seems much too lax for a full approval. I think the only reasonable fair
> criteria of success would be a public and unanimous approval by at least
> N committee members. I have no idea what N should be, but I know that if
> this test proposal can't garner N approvals, no proposal will ever pass
> the hurdle.
>
>      To make it plain, I suggest we take the number of committee members
> that comment on the test proposal as the maximum bound of N. I do hope
> max(N) > 1.
>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20181104/29e310e6/attachment.html>

From blamario at ciktel.net  Mon Nov  5 01:31:34 2018
From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Sun, 4 Nov 2018 20:31:34 -0500
Subject: LAST CALL to comment on the RelaxedPolyRec proposal
Message-ID: <cb58a27a-1926-22cd-caa4-c6a364dedcb3@ciktel.net>

I hereby officially announce that the RFC for the relaxed dependency 
analysis (https://github.com/haskell/rfcs/pull/17) has attained the 
rarefied status of Last Call. Please take some time within the following 
two weeks to vote for or against the proposal, or just leave a comment 
to indicate you're still alive but didn't form an opinion on it.



From rae at cs.brynmawr.edu  Mon Nov  5 17:18:51 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 5 Nov 2018 12:18:51 -0500
Subject: Report merged, steps to follow
In-Reply-To: <8a11390b-fbf2-ead1-7783-082d2b813e91@ciktel.net>
References: <8a11390b-fbf2-ead1-7783-082d2b813e91@ciktel.net>
Message-ID: <E64AFC8C-A28C-4853-96A6-175DE9199CB7@cs.brynmawr.edu>

Also sounds good to me. Thanks for laboriously breathing life back into this process! I will comment on the proposal sometime this week.

Richard

> On Nov 4, 2018, at 10:04 AM, Mario Blažević <blamario at ciktel.net> wrote:
> 
> Four weeks having passed since the previous discussion with no objections, I have now merged the content of the Haskell Report
> 
> from https://github.com/haskell/haskell-report
> 
> into https://github.com/haskell/rfcs
> 
> 
>     To remind everybody again, the point of this move was to enable adding an actionable change to the report to every RFC. From this point on, any proposal that passes the full process to becoming accepted can update the report by the simple act of getting merged.
> 
>     In order to test this process, over a year ago I've picked and submitted the least controversial RFC I could find, namely https://github.com/haskell/rfcs/pull/17. There has been no objection to the proposal. In fact there has been no comment whatsoever, but I suppose that's beside the point. So today I have moved the RFC to the "Last Call" column (https://github.com/haskell/rfcs/projects/1) as the first and only proposal to gain that awesome status.
> 
>     It's not at all clear what should happen to the RFC between this point and it getting merged, but I'm determined to test drive the process with it. This is my plan:
> 
> 1. I'm going to add update the report with a patch to the report content, then
> 
> 2. wait another two weeks for any objection before
> 
> 3. moving the proposal from the Last Call to the Ready for Report status, then
> 
> 4. announce that the proposal is Ready for Report and
> 
> 5. wait another two weeks for the full approval, then finally
> 
> 6. merge the RFC.
> 
> 
>     The only flaw in my cunning plan above is defining what constitutes "the full approval". The committee being rather ... disengaged and scattered, there is little hope of getting 50% of votes from all its members. The criteria of no raised objection, which I've used so far, seems much too lax for a full approval. I think the only reasonable fair criteria of success would be a public and unanimous approval by at least N committee members. I have no idea what N should be, but I know that if this test proposal can't garner N approvals, no proposal will ever pass the hurdle.
> 
>     To make it plain, I suggest we take the number of committee members that comment on the test proposal as the maximum bound of N. I do hope max(N) > 1.
> 
> 
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


From blamario at ciktel.net  Mon Nov 19 02:29:41 2018
From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Sun, 18 Nov 2018 21:29:41 -0500
Subject: LAST CALL to comment on the RelaxedPolyRec proposal
In-Reply-To: <cb58a27a-1926-22cd-caa4-c6a364dedcb3@ciktel.net>
References: <cb58a27a-1926-22cd-caa4-c6a364dedcb3@ciktel.net>
Message-ID: <97043694-741a-0bed-5375-b51b47c14839@ciktel.net>

     Having received nothing but positive responses (both of them), the 
RFC for the relaxed dependency analysis 
(https://github.com/haskell/rfcs/pull/17) has been moved to the Ready 
for Report status. I'm going to leave it there for two weeks before I 
merge it in. Just in case there is any last-minute objection or 
amendment to the proposal.


On 2018-11-04 8:31 p.m., Mario Blažević wrote:
> I hereby officially announce that the RFC for the relaxed dependency 
> analysis (https://github.com/haskell/rfcs/pull/17) has attained the 
> rarefied status of Last Call. Please take some time within the 
> following two weeks to vote for or against the proposal, or just leave 
> a comment to indicate you're still alive but didn't form an opinion on 
> it. 


From blamario at ciktel.net  Tue Nov 27 03:28:35 2018
From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Mon, 26 Nov 2018 22:28:35 -0500
Subject: The first proposal has been merged
Message-ID: <45df4185-f5eb-a60b-50a0-d75affe8039b@ciktel.net>

     Break out the champagne, because the first Haskell 2020 proposal 
has been fully merged [1]. By fully merged, I mean that the text of the 
report has been updated, so we have accomplished something material. 
Should the Haskell 2020 commitee agree so, we now have the option to 
declare the Haskell 2018 standard finished, merge the report text back 
into the official Haskell Report, and hand it over to future generations.

     Admittedly the RFC in question, -XRelaxedPolyRec, was probably the 
most trivial possible. My preference would be for the members of the 
committee to follow the lead of this proposal and apply the same process 
to more significant issues.

The process to follow is:

1. Take any RFC you're interested in from the In Discussion column of 
the repo project (https://github.com/haskell/rfcs/projects/1). 
Alternatively, write up a new proposal, put it up for discussion, and 
wait a decent time.

2. If there is no serious objection to the proposal after a while, make 
sure all technical objections are addressed and move the RFC to the Last 
Call column. Declare on the mailing list that you've done so.

3. Modify the text of the report on the same branch where the RFC is 
written up. If there is no objection to the proposal in the Last Call 
status in the following two weeks (and there is some approval), move the 
proposal into the Ready for Report column and declare so on the mailing 
list.

4. Leave at least another two weeks to refine the details of the Report 
text, then merge the RFC.

[1] https://github.com/haskell/rfcs/pull/17


From Henrik.Nilsson at nottingham.ac.uk  Tue Nov 27 08:36:24 2018
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Tue, 27 Nov 2018 08:36:24 +0000
Subject: The first proposal has been merged
In-Reply-To: <45df4185-f5eb-a60b-50a0-d75affe8039b@ciktel.net>
References: <45df4185-f5eb-a60b-50a0-d75affe8039b@ciktel.net>
Message-ID: <5BFD0208.7060508@exmail.nottingham.ac.uk>

Hi,

On 11/27/2018 03:28 AM, Mario Blažević wrote:
> Break out the champagne, because the first Haskell 2020 proposal has
> been fully merged [1].

Thank you, Mario!

/Henrik



This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.





From J.Hage at uu.nl  Wed Nov 28 07:17:42 2018
From: J.Hage at uu.nl (Jurriaan Hage)
Date: Wed, 28 Nov 2018 08:17:42 +0100
Subject: Helium II
Message-ID: <75A2D13E-CC9F-4738-92FD-6D92B04D0A05@uu.nl>

Dear all,

We’ve been active since September making the Helium compiler more Haskell 2010 compliant.
In particular, we have a branch with support for Haskell 2010 type classes, a branch that
supports import/export following the standard, and a branch that compiles to LLVM instead 
of the `old’ Helium-specific LVM that has become harder and harder to maintain.
These still need to be integrated. When I find time for that is hard to say.

Another project will be taking place in the period Feb-Apr and I expect we can tie up a lot of 
loose ends then. Current loose ends include newtype, record syntax, integration of previous projects, 
Cabal support, Quickcheck, strict data fields, improving the LLVM back-end.

One thing I have wondered about: do we actually have something like an extensive set of tests
to throw at any Haskell 2010 compliant compiler that would help find mistakes on our parr?
My students have come up with a range of examples to test their implementations, but there
is nothing like a set of programs you’ve never seen or heard about.

We shall also be adding support for GADTs as part of a reseach project this course year. Again, a large range
of examples would be welcome indeed.

best,
Jur


From blamario at ciktel.net  Wed Nov 28 14:03:30 2018
From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Wed, 28 Nov 2018 09:03:30 -0500
Subject: Helium II
In-Reply-To: <75A2D13E-CC9F-4738-92FD-6D92B04D0A05@uu.nl>
References: <75A2D13E-CC9F-4738-92FD-6D92B04D0A05@uu.nl>
Message-ID: <aba15424-9737-a3ed-4237-06ce4ccc6735@ciktel.net>

On 2018-11-28 2:17 a.m., Jurriaan Hage wrote:
> Dear all,
>
> We’ve been active since September making the Helium compiler more Haskell 2010 compliant.
> In particular, we have a branch with support for Haskell 2010 type classes, a branch that
> supports import/export following the standard, and a branch that compiles to LLVM instead
> of the `old’ Helium-specific LVM that has become harder and harder to maintain.
> These still need to be integrated. When I find time for that is hard to say.
>
> Another project will be taking place in the period Feb-Apr and I expect we can tie up a lot of
> loose ends then. Current loose ends include newtype, record syntax, integration of previous projects,
> Cabal support, Quickcheck, strict data fields, improving the LLVM back-end.
>
> One thing I have wondered about: do we actually have something like an extensive set of tests
> to throw at any Haskell 2010 compliant compiler that would help find mistakes on our parr?
> My students have come up with a range of examples to test their implementations, but there
> is nothing like a set of programs you’ve never seen or heard about.


If you want to be really thorough:

1. start with all of Hackage,

2. filter out all packages with the extensions: field in the cabal file,

3. filter out all modules with the {-# LANGUAGE ... #-} pragma,

4. recursively filter out all modules that import any filtered-out module,

5. you're left with a large set of pure Haskell 2010 modules.


     If you'd rather start small, I suspect it's best to look at the 
existing Haskell implementations. For example, there is a test suite at 
https://github.com/ajhc/ajhc/tree/arafura/regress/tests



From anthony_clayden at clear.net.nz  Wed Nov 28 22:10:02 2018
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Thu, 29 Nov 2018 11:10:02 +1300
Subject: Helium II
Message-ID: <CAM7nRYRPA2vVkR6BiQUcv+46hc9E9ANZCN9vyt2Ze_OepuWGpw@mail.gmail.com>

*On 2018-11-28 14:03:30 UTC, **Mario Blažević wrote:*

>> On 2018-11-28 2:17 a.m., Jurriaan Hage wrote:
>
>>*  do we actually have something like an extensive set of tests*
>>* to throw at any Haskell 2010 compliant compiler that would help find mistakes on our parr?*


> If you want to be really thorough:
>
> 1. start with all of Hackage,
>
> 2. filter out all packages with the extensions: field in the cabal file,
>
> 3. filter out all modules with the {-# LANGUAGE ... #-} pragma,
>
> 4. recursively filter out all modules that import any filtered-out module,
>
> 5. you're left with a large set of pure Haskell 2010 modules.

At 3.b. also filter out anything with inline pragmas like {-#
OVERLAPS/PING/ABLE, INCOHERENT #-}. Note that GHC allows "the
possibility" of instances to overlap even without any flags/pragmas
set. It's only if you try to use them that it starts insisting on
pragmas. Whereas the H2010 standard is clear that overlaps are not
allowed.

What about anything that relies on the FTP changes to Prelude? Has
Juriaan's team upgraded their Prelude?

Frankly after you've filtered out all that, I'd be astonished if you
have anything left. It seems to be usual practice on Hackage to switch
on a swag of LANGUAGE pragmas even if this module isn't using them.
(MPTCs, FlexibleInstances/Contexts in particular.)


AntC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20181129/94ffe3e7/attachment.html>

From doug at cs.dartmouth.edu  Thu Nov 29 15:00:19 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 29 Nov 2018 10:00:19 -0500
Subject: Helium II
Message-ID: <201811291500.wATF0JaX071415@tahoe.cs.Dartmouth.EDU>

> Frankly after you've filtered out all that, I'd be astonished if you
> have anything left. It seems to be usual practice on Hackage to switch
> on a swag of LANGUAGE pragmas even if this module isn't using them.
> (MPTCs, FlexibleInstances/Contexts in particular.)

A depressing remark, which comes close to saying there is
no true Haskell. It's one reason I hang mostly with Hugs.
GHC pretty well repudiates Haskell 2010. May Haskell 2020
receive more respect!

Doug

From anthony_clayden at clear.net.nz  Fri Nov 30 10:54:28 2018
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Fri, 30 Nov 2018 23:54:28 +1300
Subject: Helium II
Message-ID: <CAM7nRYTi+ynRZVL63jdteXQVFiA8NNPfUibOcJMgLWzj0hvhfQ@mail.gmail.com>

On *Thu Nov 29 15:00:19 UTC 2018, Doug McIlroy wrote:*

> >* Frankly after you've filtered out all that, I'd be astonished if you**
have anything left. It seems to be usual practice on Hackage to switch** on
a swag of LANGUAGE pragmas even if this module isn't using them.*

>>* (MPTCs, FlexibleInstances/Contexts in particular.)*

> A depressing remark, which comes close to saying
> there is no true Haskell.

? There wasn't a true Haskell in 1998. Already Hugs (in HugsMode) and
GHC (with glasgow-extns) had MPTCs, FlexibleInstances/Contexts,
FunDeps, UndecidableInstances. Overlapping instances was optional
extra.

> It's one reason I hang mostly with Hugs.

Interesting. Does that mean Hugs98? How on earth do you manage without
at least some of the above?

> GHC pretty well repudiates Haskell 2010.

So does Hugs (in HugsMode): a large proportion of the extra features
in H2010 were suggested by the Hugs teams; and Hugs 2006 was already
far advanced beyond it.


> May Haskell 2020 receive more respect!

I think you'll need to adjust your expectations: I doubt H2020 will
happen. There was a glimmer of activity last month, but this list has
resumed its moribund state. So I think we can put last month down to
dead cat bounce. If H2020 does happen, HugsMode will still be well
ahead of whatever gets added.


AntC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20181130/bab3e2c9/attachment.html>