From jmct at jmct.cc  Thu Apr 21 21:22:50 2016
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Thu, 21 Apr 2016 17:22:50 -0400
Subject: Update on Haskell Prime reboot?
Message-ID: <CAK+ijdvegND2fRaWEtbKB+nRffcrnxbDaLJzeNJ6pvB_eZ4qPQ@mail.gmail.com>

Hello all,

I'm curious if there is any progress on the reboot of the Haskell
Prime committee. It has been six months since the closing of
nominations and there hasn't been any word that I'm aware of. I've
also spoken to a few others that have self-nominated and they too have
not heard any news.

Personally, I feel that a new standard is very important for the
future health of the community. Several threads on the mailing list
and posts on the web, such as one on reddit today [1], show a desire
from the community for a major consolidation effort.

If there is any way that I can help the process along I would be glad
to do so. It would be a shame to allow for the enthusiasm for a new
committee fade away.

Cheers,

Jos?


[1]: https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/

From eir at cis.upenn.edu  Fri Apr 22 13:33:14 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 22 Apr 2016 09:33:14 -0400
Subject: Update on Haskell Prime reboot?
In-Reply-To: <CAK+ijdvegND2fRaWEtbKB+nRffcrnxbDaLJzeNJ6pvB_eZ4qPQ@mail.gmail.com>
References: <CAK+ijdvegND2fRaWEtbKB+nRffcrnxbDaLJzeNJ6pvB_eZ4qPQ@mail.gmail.com>
Message-ID: <C82EBB7B-F4F0-46D2-9F69-BED704652FC8@cis.upenn.edu>

I stand by ready to debate standards and would enjoy moving this process forward. However, I'm not in a position where I can lead at the moment -- just too consumed by other tasks right now.

As a concrete suggestion, I wonder if we should have two goals:

1. Write down an updated standard for Haskell.

2. Write down pre-standards for several extensions.

About (2): I'm very sympathetic to a recent post on Haskell-cafe about having formal descriptions of language extensions. It is not our purview to document GHC. However, several extensions are in very common use, but might not be quite ready for a language standard. Chief among these, in my opinion, is GADTs. GADTs are problematic from a standardization standpoint because it's quite hard to specify when a GADT pattern-match type-checks, without resorting to discussion of unification variables. For this reason, I would be hesitant about putting GADTs in a standard. On the other hand, it shouldn't be too hard to specify some sort of minimum implementation that individual compilers can build on. I'm calling such a description a "pre-standard".

Thoughts?

Richard

On Apr 21, 2016, at 5:22 PM, Jos? Manuel Calder?n Trilla <jmct at jmct.cc> wrote:

> Hello all,
> 
> I'm curious if there is any progress on the reboot of the Haskell
> Prime committee. It has been six months since the closing of
> nominations and there hasn't been any word that I'm aware of. I've
> also spoken to a few others that have self-nominated and they too have
> not heard any news.
> 
> Personally, I feel that a new standard is very important for the
> future health of the community. Several threads on the mailing list
> and posts on the web, such as one on reddit today [1], show a desire
> from the community for a major consolidation effort.
> 
> If there is any way that I can help the process along I would be glad
> to do so. It would be a shame to allow for the enthusiasm for a new
> committee fade away.
> 
> Cheers,
> 
> Jos?
> 
> 
> [1]: https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> 


From jmct at jmct.cc  Fri Apr 22 17:55:06 2016
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Fri, 22 Apr 2016 13:55:06 -0400
Subject: Update on Haskell Prime reboot?
In-Reply-To: <C82EBB7B-F4F0-46D2-9F69-BED704652FC8@cis.upenn.edu>
References: <CAK+ijdvegND2fRaWEtbKB+nRffcrnxbDaLJzeNJ6pvB_eZ4qPQ@mail.gmail.com>
 <C82EBB7B-F4F0-46D2-9F69-BED704652FC8@cis.upenn.edu>
Message-ID: <CAK+ijdtH6xOTRwRJoGeST3TWbC5v0zvmLJXs-Xdu5ZjSLZMjEA@mail.gmail.com>

Hi Richard,

> As a concrete suggestion, I wonder if we should have two goals:
>
> 1. Write down an updated standard for Haskell.
>
> 2. Write down pre-standards for several extensions.

I agree with both of these. It may even be useful to use goal 2 as a
stepping stone to determine what extensions should receive the extra
attention necessary (if any) to be part of goal 1. Were you thinking
that these pre-standards would look something like Mark Jones's
'Typing Haskell in Haskell' paper? A simplified and clear
specification in the form of a Haskell program would go a long way in
clarifying the meaning of certain extensions. To use your example, you
could imagine an implementation of GADTs that forms the baseline of
what the GADT extension should mean (implementations should accept at
least what this one does). That might be too ambitious though.

A lot of the 'obvious' extensions were discussed that last time the
Haskell Prime committee was active, so a lot of groundwork has been
laid already. The most important step right now is empowering people
to move forward with the process.

Herbert Valerio Riedel is the chair of the reboot, and as such gets
final say on who is a member of the committee and any timeline for
deciding. That being said, I think the aim should be to have the
committee membership decided soon and start discussing what the
priorities should be. I'm partial to suggesting a face to face meeting
at ICFP, but realize that it is difficult for many to attend to ICFP.

Cheers,

Jos?


On Fri, Apr 22, 2016 at 9:33 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> I stand by ready to debate standards and would enjoy moving this process forward. However, I'm not in a position where I can lead at the moment -- just too consumed by other tasks right now.
>
> As a concrete suggestion, I wonder if we should have two goals:
>
> 1. Write down an updated standard for Haskell.
>
> 2. Write down pre-standards for several extensions.
>
> About (2): I'm very sympathetic to a recent post on Haskell-cafe about having formal descriptions of language extensions. It is not our purview to document GHC. However, several extensions are in very common use, but might not be quite ready for a language standard. Chief among these, in my opinion, is GADTs. GADTs are problematic from a standardization standpoint because it's quite hard to specify when a GADT pattern-match type-checks, without resorting to discussion of unification variables. For this reason, I would be hesitant about putting GADTs in a standard. On the other hand, it shouldn't be too hard to specify some sort of minimum implementation that individual compilers can build on. I'm calling such a description a "pre-standard".
>
> Thoughts?
>
> Richard
>
> On Apr 21, 2016, at 5:22 PM, Jos? Manuel Calder?n Trilla <jmct at jmct.cc> wrote:
>
>> Hello all,
>>
>> I'm curious if there is any progress on the reboot of the Haskell
>> Prime committee. It has been six months since the closing of
>> nominations and there hasn't been any word that I'm aware of. I've
>> also spoken to a few others that have self-nominated and they too have
>> not heard any news.
>>
>> Personally, I feel that a new standard is very important for the
>> future health of the community. Several threads on the mailing list
>> and posts on the web, such as one on reddit today [1], show a desire
>> from the community for a major consolidation effort.
>>
>> If there is any way that I can help the process along I would be glad
>> to do so. It would be a shame to allow for the enthusiasm for a new
>> committee fade away.
>>
>> Cheers,
>>
>> Jos?
>>
>>
>> [1]: https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>

From flippa at flippac.org  Fri Apr 22 19:45:11 2016
From: flippa at flippac.org (Philippa Cowderoy)
Date: Fri, 22 Apr 2016 20:45:11 +0100
Subject: Update on Haskell Prime reboot?
In-Reply-To: <CAK+ijdtH6xOTRwRJoGeST3TWbC5v0zvmLJXs-Xdu5ZjSLZMjEA@mail.gmail.com>
References: <CAK+ijdvegND2fRaWEtbKB+nRffcrnxbDaLJzeNJ6pvB_eZ4qPQ@mail.gmail.com>
 <C82EBB7B-F4F0-46D2-9F69-BED704652FC8@cis.upenn.edu>
 <CAK+ijdtH6xOTRwRJoGeST3TWbC5v0zvmLJXs-Xdu5ZjSLZMjEA@mail.gmail.com>
Message-ID: <571A7F47.8090407@flippac.org>

In all honesty, Typing Haskell in Haskell is about as far as anyone 
should push typechecking and type inference while claiming to still work 
in a functional style. I don't think a good GADT pre-spec looks like 
functional programming at all, it's a [constraint] logic programming 
problem and part of what we're looking to establish is the minimum 
information flow people can expect during inference for a given amount 
of syntactic effort.

I'm not saying I never write the implementations in haskell! But they 
tend to involve a lot of "how to implement the constraint system" and 
then a bunch of transliterated typing rules. A good spec for "enough 
annotation this should work easily" would be useful as something that 
permits other implementations to experiment with different extensions in 
combination though!

On 22/04/2016 18:55, Jos? Manuel Calder?n Trilla wrote:
> Hi Richard,
>
>> As a concrete suggestion, I wonder if we should have two goals:
>>
>> 1. Write down an updated standard for Haskell.
>>
>> 2. Write down pre-standards for several extensions.
> I agree with both of these. It may even be useful to use goal 2 as a
> stepping stone to determine what extensions should receive the extra
> attention necessary (if any) to be part of goal 1. Were you thinking
> that these pre-standards would look something like Mark Jones's
> 'Typing Haskell in Haskell' paper? A simplified and clear
> specification in the form of a Haskell program would go a long way in
> clarifying the meaning of certain extensions. To use your example, you
> could imagine an implementation of GADTs that forms the baseline of
> what the GADT extension should mean (implementations should accept at
> least what this one does). That might be too ambitious though.
>
> A lot of the 'obvious' extensions were discussed that last time the
> Haskell Prime committee was active, so a lot of groundwork has been
> laid already. The most important step right now is empowering people
> to move forward with the process.
>
> Herbert Valerio Riedel is the chair of the reboot, and as such gets
> final say on who is a member of the committee and any timeline for
> deciding. That being said, I think the aim should be to have the
> committee membership decided soon and start discussing what the
> priorities should be. I'm partial to suggesting a face to face meeting
> at ICFP, but realize that it is difficult for many to attend to ICFP.
>
> Cheers,
>
> Jos?
>
>
> On Fri, Apr 22, 2016 at 9:33 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>> I stand by ready to debate standards and would enjoy moving this process forward. However, I'm not in a position where I can lead at the moment -- just too consumed by other tasks right now.
>>
>> As a concrete suggestion, I wonder if we should have two goals:
>>
>> 1. Write down an updated standard for Haskell.
>>
>> 2. Write down pre-standards for several extensions.
>>
>> About (2): I'm very sympathetic to a recent post on Haskell-cafe about having formal descriptions of language extensions. It is not our purview to document GHC. However, several extensions are in very common use, but might not be quite ready for a language standard. Chief among these, in my opinion, is GADTs. GADTs are problematic from a standardization standpoint because it's quite hard to specify when a GADT pattern-match type-checks, without resorting to discussion of unification variables. For this reason, I would be hesitant about putting GADTs in a standard. On the other hand, it shouldn't be too hard to specify some sort of minimum implementation that individual compilers can build on. I'm calling such a description a "pre-standard".
>>
>> Thoughts?
>>
>> Richard
>>
>> On Apr 21, 2016, at 5:22 PM, Jos? Manuel Calder?n Trilla <jmct at jmct.cc> wrote:
>>
>>> Hello all,
>>>
>>> I'm curious if there is any progress on the reboot of the Haskell
>>> Prime committee. It has been six months since the closing of
>>> nominations and there hasn't been any word that I'm aware of. I've
>>> also spoken to a few others that have self-nominated and they too have
>>> not heard any news.
>>>
>>> Personally, I feel that a new standard is very important for the
>>> future health of the community. Several threads on the mailing list
>>> and posts on the web, such as one on reddit today [1], show a desire
>>> from the community for a major consolidation effort.
>>>
>>> If there is any way that I can help the process along I would be glad
>>> to do so. It would be a shame to allow for the enthusiasm for a new
>>> committee fade away.
>>>
>>> Cheers,
>>>
>>> Jos?
>>>
>>>
>>> [1]: https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/
>>> _______________________________________________
>>> Haskell-prime mailing list
>>> Haskell-prime at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


From mail at andres-loeh.de  Fri Apr 22 19:49:28 2016
From: mail at andres-loeh.de (Andres Loeh)
Date: Fri, 22 Apr 2016 21:49:28 +0200
Subject: Update on Haskell Prime reboot?
In-Reply-To: <CAK+ijdtH6xOTRwRJoGeST3TWbC5v0zvmLJXs-Xdu5ZjSLZMjEA@mail.gmail.com>
References: <CAK+ijdvegND2fRaWEtbKB+nRffcrnxbDaLJzeNJ6pvB_eZ4qPQ@mail.gmail.com>
 <C82EBB7B-F4F0-46D2-9F69-BED704652FC8@cis.upenn.edu>
 <CAK+ijdtH6xOTRwRJoGeST3TWbC5v0zvmLJXs-Xdu5ZjSLZMjEA@mail.gmail.com>
Message-ID: <CALjd_v7PqvfVpYMndri-P+DMo6+8T9RCL1amjOX0he_iymjfEA@mail.gmail.com>

Hi.

I've been talking to Herbert from time to time, and I know he's having
a draft announcement lying around, and is still planning on properly
starting the process soon, and has (this is my opinion, not his) just
been falling into the trap of waiting for a "good moment" which then
never comes.

I'm personally still eager to get the discussions about a new standard started.

While it's true that the old Haskell Prime committee has been doing
good work in creating some sort of catalogue of issues and extensions
at the time, it's still far from proper standardization. And indeed, I
think the bulk of the work that goes into a new standard in my opinon
is to work out all the corner cases and the actual specification of
the extensions. It's less important which ones ultimately go in or
stay out, but actually specfiying them properly is already going to be
a good step forward.

Cheers,
  Andres


On Fri, Apr 22, 2016 at 7:55 PM, Jos? Manuel Calder?n Trilla
<jmct at jmct.cc> wrote:
> Hi Richard,
>
>> As a concrete suggestion, I wonder if we should have two goals:
>>
>> 1. Write down an updated standard for Haskell.
>>
>> 2. Write down pre-standards for several extensions.
>
> I agree with both of these. It may even be useful to use goal 2 as a
> stepping stone to determine what extensions should receive the extra
> attention necessary (if any) to be part of goal 1. Were you thinking
> that these pre-standards would look something like Mark Jones's
> 'Typing Haskell in Haskell' paper? A simplified and clear
> specification in the form of a Haskell program would go a long way in
> clarifying the meaning of certain extensions. To use your example, you
> could imagine an implementation of GADTs that forms the baseline of
> what the GADT extension should mean (implementations should accept at
> least what this one does). That might be too ambitious though.
>
> A lot of the 'obvious' extensions were discussed that last time the
> Haskell Prime committee was active, so a lot of groundwork has been
> laid already. The most important step right now is empowering people
> to move forward with the process.
>
> Herbert Valerio Riedel is the chair of the reboot, and as such gets
> final say on who is a member of the committee and any timeline for
> deciding. That being said, I think the aim should be to have the
> committee membership decided soon and start discussing what the
> priorities should be. I'm partial to suggesting a face to face meeting
> at ICFP, but realize that it is difficult for many to attend to ICFP.
>
> Cheers,
>
> Jos?
>
>
> On Fri, Apr 22, 2016 at 9:33 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>> I stand by ready to debate standards and would enjoy moving this process forward. However, I'm not in a position where I can lead at the moment -- just too consumed by other tasks right now.
>>
>> As a concrete suggestion, I wonder if we should have two goals:
>>
>> 1. Write down an updated standard for Haskell.
>>
>> 2. Write down pre-standards for several extensions.
>>
>> About (2): I'm very sympathetic to a recent post on Haskell-cafe about having formal descriptions of language extensions. It is not our purview to document GHC. However, several extensions are in very common use, but might not be quite ready for a language standard. Chief among these, in my opinion, is GADTs. GADTs are problematic from a standardization standpoint because it's quite hard to specify when a GADT pattern-match type-checks, without resorting to discussion of unification variables. For this reason, I would be hesitant about putting GADTs in a standard. On the other hand, it shouldn't be too hard to specify some sort of minimum implementation that individual compilers can build on. I'm calling such a description a "pre-standard".
>>
>> Thoughts?
>>
>> Richard
>>
>> On Apr 21, 2016, at 5:22 PM, Jos? Manuel Calder?n Trilla <jmct at jmct.cc> wrote:
>>
>>> Hello all,
>>>
>>> I'm curious if there is any progress on the reboot of the Haskell
>>> Prime committee. It has been six months since the closing of
>>> nominations and there hasn't been any word that I'm aware of. I've
>>> also spoken to a few others that have self-nominated and they too have
>>> not heard any news.
>>>
>>> Personally, I feel that a new standard is very important for the
>>> future health of the community. Several threads on the mailing list
>>> and posts on the web, such as one on reddit today [1], show a desire
>>> from the community for a major consolidation effort.
>>>
>>> If there is any way that I can help the process along I would be glad
>>> to do so. It would be a shame to allow for the enthusiasm for a new
>>> committee fade away.
>>>
>>> Cheers,
>>>
>>> Jos?
>>>
>>>
>>> [1]: https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/
>>> _______________________________________________
>>> Haskell-prime mailing list
>>> Haskell-prime at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>>
>>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

From flippa at flippac.org  Fri Apr 22 20:02:19 2016
From: flippa at flippac.org (Philippa Cowderoy)
Date: Fri, 22 Apr 2016 21:02:19 +0100
Subject: Update on Haskell Prime reboot?
In-Reply-To: <CALjd_v7PqvfVpYMndri-P+DMo6+8T9RCL1amjOX0he_iymjfEA@mail.gmail.com>
References: <CAK+ijdvegND2fRaWEtbKB+nRffcrnxbDaLJzeNJ6pvB_eZ4qPQ@mail.gmail.com>
 <C82EBB7B-F4F0-46D2-9F69-BED704652FC8@cis.upenn.edu>
 <CAK+ijdtH6xOTRwRJoGeST3TWbC5v0zvmLJXs-Xdu5ZjSLZMjEA@mail.gmail.com>
 <CALjd_v7PqvfVpYMndri-P+DMo6+8T9RCL1amjOX0he_iymjfEA@mail.gmail.com>
Message-ID: <571A834B.1090108@flippac.org>

Agreed - the appropriate means for specifying the type system is 
something I'm not sure we have a truly good answer for at this point 
alas. We're way past being able to rely on an informal "H-M + 
constraints from typeclasses" style description if we want to describe 
even extensions that have been around 15+ years.

(I am not on the committee etc etc, just have spent much time pondering 
related issues!)

On 22/04/2016 20:49, Andres Loeh wrote:
> Hi.
>
> I've been talking to Herbert from time to time, and I know he's having
> a draft announcement lying around, and is still planning on properly
> starting the process soon, and has (this is my opinion, not his) just
> been falling into the trap of waiting for a "good moment" which then
> never comes.
>
> I'm personally still eager to get the discussions about a new standard started.
>
> While it's true that the old Haskell Prime committee has been doing
> good work in creating some sort of catalogue of issues and extensions
> at the time, it's still far from proper standardization. And indeed, I
> think the bulk of the work that goes into a new standard in my opinon
> is to work out all the corner cases and the actual specification of
> the extensions. It's less important which ones ultimately go in or
> stay out, but actually specfiying them properly is already going to be
> a good step forward.
>
> Cheers,
>    Andres
>
>
> On Fri, Apr 22, 2016 at 7:55 PM, Jos? Manuel Calder?n Trilla
> <jmct at jmct.cc> wrote:
>> Hi Richard,
>>
>>> As a concrete suggestion, I wonder if we should have two goals:
>>>
>>> 1. Write down an updated standard for Haskell.
>>>
>>> 2. Write down pre-standards for several extensions.
>> I agree with both of these. It may even be useful to use goal 2 as a
>> stepping stone to determine what extensions should receive the extra
>> attention necessary (if any) to be part of goal 1. Were you thinking
>> that these pre-standards would look something like Mark Jones's
>> 'Typing Haskell in Haskell' paper? A simplified and clear
>> specification in the form of a Haskell program would go a long way in
>> clarifying the meaning of certain extensions. To use your example, you
>> could imagine an implementation of GADTs that forms the baseline of
>> what the GADT extension should mean (implementations should accept at
>> least what this one does). That might be too ambitious though.
>>
>> A lot of the 'obvious' extensions were discussed that last time the
>> Haskell Prime committee was active, so a lot of groundwork has been
>> laid already. The most important step right now is empowering people
>> to move forward with the process.
>>
>> Herbert Valerio Riedel is the chair of the reboot, and as such gets
>> final say on who is a member of the committee and any timeline for
>> deciding. That being said, I think the aim should be to have the
>> committee membership decided soon and start discussing what the
>> priorities should be. I'm partial to suggesting a face to face meeting
>> at ICFP, but realize that it is difficult for many to attend to ICFP.
>>
>> Cheers,
>>
>> Jos?
>>
>>
>> On Fri, Apr 22, 2016 at 9:33 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>>> I stand by ready to debate standards and would enjoy moving this process forward. However, I'm not in a position where I can lead at the moment -- just too consumed by other tasks right now.
>>>
>>> As a concrete suggestion, I wonder if we should have two goals:
>>>
>>> 1. Write down an updated standard for Haskell.
>>>
>>> 2. Write down pre-standards for several extensions.
>>>
>>> About (2): I'm very sympathetic to a recent post on Haskell-cafe about having formal descriptions of language extensions. It is not our purview to document GHC. However, several extensions are in very common use, but might not be quite ready for a language standard. Chief among these, in my opinion, is GADTs. GADTs are problematic from a standardization standpoint because it's quite hard to specify when a GADT pattern-match type-checks, without resorting to discussion of unification variables. For this reason, I would be hesitant about putting GADTs in a standard. On the other hand, it shouldn't be too hard to specify some sort of minimum implementation that individual compilers can build on. I'm calling such a description a "pre-standard".
>>>
>>> Thoughts?
>>>
>>> Richard
>>>
>>> On Apr 21, 2016, at 5:22 PM, Jos? Manuel Calder?n Trilla <jmct at jmct.cc> wrote:
>>>
>>>> Hello all,
>>>>
>>>> I'm curious if there is any progress on the reboot of the Haskell
>>>> Prime committee. It has been six months since the closing of
>>>> nominations and there hasn't been any word that I'm aware of. I've
>>>> also spoken to a few others that have self-nominated and they too have
>>>> not heard any news.
>>>>
>>>> Personally, I feel that a new standard is very important for the
>>>> future health of the community. Several threads on the mailing list
>>>> and posts on the web, such as one on reddit today [1], show a desire
>>>> from the community for a major consolidation effort.
>>>>
>>>> If there is any way that I can help the process along I would be glad
>>>> to do so. It would be a shame to allow for the enthusiasm for a new
>>>> committee fade away.
>>>>
>>>> Cheers,
>>>>
>>>> Jos?
>>>>
>>>>
>>>> [1]: https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/
>>>> _______________________________________________
>>>> Haskell-prime mailing list
>>>> Haskell-prime at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>>>
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


From hvriedel at gmail.com  Thu Apr 28 09:57:54 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 28 Apr 2016 11:57:54 +0200
Subject: ANN: Haskell Prime 2020 committee has formed
Message-ID: <874mamjbrx.fsf@gmail.com>

Dear Haskell Community!

Some time ago I asked for nominations to reboot the Haskell Prime
process[1], and now I'm pleased to finally announce the formation of
the new Haskell Language 2020 Committee!

The goal of the Haskell Language committee together with the Core
Libraries Committee is to work towards a new Haskell 2020 Language
Report.  I'd like to remind everyone that the Haskell Prime Process[4]
relies on *everyone* in the community to help by contributing proposals
which the committee will then evaluate and if suitable help formalise
for inclusion. Everyone interested in participating is also invited to
join the haskell-prime mailing list.

Four years (or rather ~3.5 years) from now may seem like a long
time. However, given the magnitude of the task at hand, to discuss,
formalise, and implement proposed extensions (taking into account the
recently enacted three-release-policy[3]) to the Haskell Report, the
process shouldn't be rushed. Consequently, this may even turn out to
be a tight schedule after all.  However, it's not excluded there
may be an interim revision of the Haskell Report before 2020.

Based on this schedule, GHC 8.8 (likely to be released early 2020)
would be the first GHC release to feature Haskell 2020
compliance. Prior GHC releases may be able to provide varying degree
of conformance to drafts of the upcoming Haskell 2020 Report.

The Haskell Language 2020 committee starts out with 20 members which
contribute a diversified skill-set.  These initial members also
represent the Haskell community from the perspective of
practitioners, implementers, educators, and researchers.

 - Andres L?h
 - Antonio Nikishaev
 - Austin Seipp
 - Carlos Camarao de Figueiredo
 - Carter Schonwald
 - David Luposchainsky
 - Henk-Jan van Tuyl
 - Henrik Nilsson
 - Herbert Valerio Riedel
 - Iavor Diatchki
 - John Wiegley
 - Jos? Manuel Calder?n Trilla
 - Jurriaan Hage
 - Lennart Augustsson
 - M Farkas-Dyck
 - Mario Bla?evi?
 - Nicolas Wu
 - Richard Eisenberg
 - Vitaly Bragilevsky
 - Wren Romano

The Haskell 2020 committee is a language committee; it will focus its
efforts on specifying the Haskell language itself. Responsibility for
the libraries laid out in the Report is left to the Core Libraries
Committee (CLC)[5]. Incidentally, the CLC still has an available
seat[2]; if you would like to contribute to the Haskell 2020 Core
Libraries you are encouraged to apply for this opening.

As this is a general announcement broadcasted to multiple mailing lists,
a separate email discussing the next steps of the new committee will be
sent to the haskell-prime mailing list shortly.  


 [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
 [2]: https://mail.haskell.org/pipermail/libraries/2015-November/026497.html
 [3]: https://prime.haskell.org/wiki/Libraries/3-Release-Policy
 [4]: https://prime.haskell.org/wiki/Process
 [5]: https://prime.haskell.org/wiki/Libraries


-- hvr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160428/7051d06b/attachment.sig>

From howard_b_golden at yahoo.com  Thu Apr 28 16:52:25 2016
From: howard_b_golden at yahoo.com (Howard B. Golden)
Date: Thu, 28 Apr 2016 16:52:25 +0000 (UTC)
Subject: Haskell Prime 2020 committee
In-Reply-To: <mailman.15.1461844802.25881.haskell-prime@haskell.org>
References: <mailman.15.1461844802.25881.haskell-prime@haskell.org>
Message-ID: <933456674.4396531.1461862345853.JavaMail.yahoo@mail.yahoo.com>

I request that the committee members create a Haskell Prime page on the Haskell wiki with capsule descriptions of their affiliations, Haskell experience and links to their home pages. I believe this will help make the process more transparent to the community. Thanks.

Howard

From eir at cis.upenn.edu  Thu Apr 28 17:45:15 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 28 Apr 2016 13:45:15 -0400
Subject: Haskell Prime 2020 committee
In-Reply-To: <933456674.4396531.1461862345853.JavaMail.yahoo@mail.yahoo.com>
References: <mailman.15.1461844802.25881.haskell-prime@haskell.org>
 <933456674.4396531.1461862345853.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <4AA2B94E-A522-4A5D-9A1A-EAD6BED63C40@cis.upenn.edu>

Seems reasonable. I have started the page at https://wiki.haskell.org/Language/HaskellPrime

Richard

On Apr 28, 2016, at 12:52 PM, Howard B. Golden <howard_b_golden at yahoo.com> wrote:

> I request that the committee members create a Haskell Prime page on the Haskell wiki with capsule descriptions of their affiliations, Haskell experience and links to their home pages. I believe this will help make the process more transparent to the community. Thanks.
> 
> Howard
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


From me at lelf.lu  Thu Apr 28 18:24:07 2016
From: me at lelf.lu (Antonio Nikishaev)
Date: Thu, 28 Apr 2016 22:24:07 +0400
Subject: Haskell Prime 2020 committee
In-Reply-To: <4AA2B94E-A522-4A5D-9A1A-EAD6BED63C40@cis.upenn.edu>
References: <mailman.15.1461844802.25881.haskell-prime@haskell.org>
 <933456674.4396531.1461862345853.JavaMail.yahoo@mail.yahoo.com>
 <4AA2B94E-A522-4A5D-9A1A-EAD6BED63C40@cis.upenn.edu>
Message-ID: <7C7D2193-1A41-45EE-82A5-8AFAD749F2D3@lelf.lu>

Should it be under prime.haskell.org instead?

(I don't seem to be able to register there though, ?Username doesn't match local naming policy.?)


-- lelf



> On 28 Apr 2016, at 21:45, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> 
> Seems reasonable. I have started the page at https://wiki.haskell.org/Language/HaskellPrime
> 
> Richard
> 
> On Apr 28, 2016, at 12:52 PM, Howard B. Golden <howard_b_golden at yahoo.com> wrote:
> 
>> I request that the committee members create a Haskell Prime page on the Haskell wiki with capsule descriptions of their affiliations, Haskell experience and links to their home pages. I believe this will help make the process more transparent to the community. Thanks.
>> 
>> Howard
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> 
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime



-- lelf




From wren at community.haskell.org  Thu Apr 28 21:13:39 2016
From: wren at community.haskell.org (wren romano)
Date: Thu, 28 Apr 2016 17:13:39 -0400
Subject: Haskell Prime 2020 committee
In-Reply-To: <7C7D2193-1A41-45EE-82A5-8AFAD749F2D3@lelf.lu>
References: <mailman.15.1461844802.25881.haskell-prime@haskell.org>
 <933456674.4396531.1461862345853.JavaMail.yahoo@mail.yahoo.com>
 <4AA2B94E-A522-4A5D-9A1A-EAD6BED63C40@cis.upenn.edu>
 <7C7D2193-1A41-45EE-82A5-8AFAD749F2D3@lelf.lu>
Message-ID: <CABUjdS4usWuFW+8k8QDtTv=5_48pzqh8BkJa5pswteteo7D=tA@mail.gmail.com>

On Thu, Apr 28, 2016 at 2:24 PM, Antonio Nikishaev <me at lelf.lu> wrote:
>> On 28 Apr 2016, at 21:45, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>> Seems reasonable. I have started the page at https://wiki.haskell.org/Language/HaskellPrime
>
> Should it be under prime.haskell.org instead?
>
> (I don't seem to be able to register there though, ?Username doesn't match local naming policy.?)

The idea seems reasonable, but I also can't set up an account on the wiki...


-- 
Live well,
~wren

From jmct at jmct.cc  Thu Apr 28 21:19:51 2016
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Thu, 28 Apr 2016 17:19:51 -0400
Subject: Haskell Prime 2020 committee
In-Reply-To: <CABUjdS4usWuFW+8k8QDtTv=5_48pzqh8BkJa5pswteteo7D=tA@mail.gmail.com>
References: <mailman.15.1461844802.25881.haskell-prime@haskell.org>
 <933456674.4396531.1461862345853.JavaMail.yahoo@mail.yahoo.com>
 <4AA2B94E-A522-4A5D-9A1A-EAD6BED63C40@cis.upenn.edu>
 <7C7D2193-1A41-45EE-82A5-8AFAD749F2D3@lelf.lu>
 <CABUjdS4usWuFW+8k8QDtTv=5_48pzqh8BkJa5pswteteo7D=tA@mail.gmail.com>
Message-ID: <CAK+ijdv0TfWKq1D1pEcMntditNs67YTVErF631w+2wKNb0so0A@mail.gmail.com>

There seems to be a minimum of 5 characters for a username, which was
giving me the ?Username doesn't match local naming policy.? error.

I was able to make an account with a longer username, but I am not
able to edit the wiki. Unsure if it's some sort of anti-spam delay or
some other issue with permissions.

-Jose

On Thu, Apr 28, 2016 at 5:13 PM, wren romano <wren at community.haskell.org> wrote:
> On Thu, Apr 28, 2016 at 2:24 PM, Antonio Nikishaev <me at lelf.lu> wrote:
>>> On 28 Apr 2016, at 21:45, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>>> Seems reasonable. I have started the page at https://wiki.haskell.org/Language/HaskellPrime
>>
>> Should it be under prime.haskell.org instead?
>>
>> (I don't seem to be able to register there though, ?Username doesn't match local naming policy.?)
>
> The idea seems reasonable, but I also can't set up an account on the wiki...
>
>
> --
> Live well,
> ~wren
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

From wren at community.haskell.org  Thu Apr 28 21:28:11 2016
From: wren at community.haskell.org (wren romano)
Date: Thu, 28 Apr 2016 17:28:11 -0400
Subject: Haskell Prime 2020 committee
In-Reply-To: <CAK+ijdv0TfWKq1D1pEcMntditNs67YTVErF631w+2wKNb0so0A@mail.gmail.com>
References: <mailman.15.1461844802.25881.haskell-prime@haskell.org>
 <933456674.4396531.1461862345853.JavaMail.yahoo@mail.yahoo.com>
 <4AA2B94E-A522-4A5D-9A1A-EAD6BED63C40@cis.upenn.edu>
 <7C7D2193-1A41-45EE-82A5-8AFAD749F2D3@lelf.lu>
 <CABUjdS4usWuFW+8k8QDtTv=5_48pzqh8BkJa5pswteteo7D=tA@mail.gmail.com>
 <CAK+ijdv0TfWKq1D1pEcMntditNs67YTVErF631w+2wKNb0so0A@mail.gmail.com>
Message-ID: <CABUjdS7kCVMhd+=vd03zgDcp=gNC1NP18i59XPfi55ZzHE2=Yw@mail.gmail.com>

On Thu, Apr 28, 2016 at 5:19 PM, Jos? Manuel Calder?n Trilla
<jmct at jmct.cc> wrote:
> There seems to be a minimum of 5 characters for a username, which was
> giving me the ?Username doesn't match local naming policy.? error.
>
> I was able to make an account with a longer username, but I am not
> able to edit the wiki. Unsure if it's some sort of anti-spam delay or
> some other issue with permissions.

The issue I had wasn't about the local naming policy, but a
no-permissions error since I'm not an admin

-- 
Live well,
~wren

From hvriedel at gmail.com  Thu Apr 28 21:56:51 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 28 Apr 2016 23:56:51 +0200
Subject: Infrastructure & Communication
Message-ID: <87pot9ieho.fsf@gmail.com>

Hello Fellow Committee Members!


Following up on the official announcement, here's a few basic things we
should get agreement over before proceeding.  First off, I'm hoping we
can manage to avoid confusing email-threading in the interest of finding
information easier lateron in the email archives. To this end, I'd like
to ask you to consider changing the subject of your reply if you realise
that the topic discussed is diverging significantly from the one
advertised in the Subject-header. 

I'll start with the following basic topic

## Infrastructure & Communication

Obviously, we have *this* public (archived) mailing list
"haskell-prime at haskell.org". There's also a (registered) IRC channel
"#haskell-prime" on freenode where many of us will probably hang around.


In the past, the Prime committee used Trac (currently
at https://prime.haskell.org/ ) to organise its work.
Trac provides a wiki, source-browser, and a ticket tracker (which is
familiar to GHC developers, and e.g. allows easy migration of
wiki-content to/from the GHC Wiki).

Some time ago, I converted the original Haskell-Report Darcs
repositories into a single Git repository (with branches) at GitHub

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

This repo is setup to be mirrored to

 - https://git.haskell.org/haskell-report.git

which in turn is also accessible from within Trac at

 - https://prime.haskell.org/browser


However, since Trac has accumulated quite a bit of old content in its
ticket-tracker over the years, and "Haskell 2020" has been coined a
reboot. Maybe it wouldn't be such a bad idea to start over at GitHub,
and consider the Trac instance mostly as a legacy archive of historic
content.


GitHub allows for Git-based workflows, and there's prior art related to
language design we could steal ideas from, for instance:

 - https://github.com/fsharp/FSharpLangDesign
 - https://github.com/rust-lang/rfcs
 - https://github.com/golang/proposal
 - (any others noteworthy?)

IMO, GitHub's issue tracker has become flexible enough for our needs and
its integration with Git pull-requests allows to e.g. group together
change proposal description/motivation, discussion, and finaly the delta
to the haskell-report (with inline annotations/reviews) and so on.
(However, I consider GitHub's Wiki-component quite weak. I'm not sure
what to do about that. Maybe keep using Trac's wiki for that?)


Moreover, we can have CI (I've actually set up a TravisCI job which
builds the LaTeX code) for the Haskell Language report drafts.

One benefit I see from using GitHub is that this way would we be closer
to the Haskell community (given the majority of Hackage packages are
hosted on GitHub), and our work would be more transparent for the
community as well as offering a lower barrier to
participation/contribution.

Moreover, I think GitHub would also help make our efforts/progress
towards a revised Haskell Report more visible to the community, which in
turn may even provide us the motivation to carry on...

So...

Does anyone object to using GitHub?

In case there's no objection, which of the existing language-design
GitHub projects do you consider a good fit for Haskell Prime and
therefore worthy of imitation?

Any other comments/suggestions?



Cheers,
  HVR
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160428/99d0f62a/attachment.sig>

From hvriedel at gmail.com  Thu Apr 28 22:22:38 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Fri, 29 Apr 2016 00:22:38 +0200
Subject: Haskell Prime 2020 committee
In-Reply-To: <CABUjdS7kCVMhd+=vd03zgDcp=gNC1NP18i59XPfi55ZzHE2=Yw@mail.gmail.com>
 (wren romano's message of "Thu, 28 Apr 2016 17:28:11 -0400")
References: <mailman.15.1461844802.25881.haskell-prime@haskell.org>
 <933456674.4396531.1461862345853.JavaMail.yahoo@mail.yahoo.com>
 <4AA2B94E-A522-4A5D-9A1A-EAD6BED63C40@cis.upenn.edu>
 <7C7D2193-1A41-45EE-82A5-8AFAD749F2D3@lelf.lu>
 <CABUjdS4usWuFW+8k8QDtTv=5_48pzqh8BkJa5pswteteo7D=tA@mail.gmail.com>
 <CAK+ijdv0TfWKq1D1pEcMntditNs67YTVErF631w+2wKNb0so0A@mail.gmail.com>
 <CABUjdS7kCVMhd+=vd03zgDcp=gNC1NP18i59XPfi55ZzHE2=Yw@mail.gmail.com>
Message-ID: <87inz1idap.fsf@gmail.com>

Hello,

On 2016-04-28 at 23:28:11 +0200, wren romano wrote:
> On Thu, Apr 28, 2016 at 5:19 PM, Jos? Manuel Calder?n Trilla
> <jmct at jmct.cc> wrote:
>> There seems to be a minimum of 5 characters for a username, which was
>> giving me the ?Username doesn't match local naming policy.? error.
>>
>> I was able to make an account with a longer username, but I am not
>> able to edit the wiki. Unsure if it's some sort of anti-spam delay or
>> some other issue with permissions.
>
> The issue I had wasn't about the local naming policy, but a
> no-permissions error since I'm not an admin

The reason is that Prime's Trac instance has been traditionally locked
down to allow only prime members write access, as well as granting
temporary permissions to external contributors working on drafting
proposals.


If anyone is having troubles registering his/her preferred account-name, or
if you have already registered an account and need it granted actual
write-permissions, please reply to me privately, and I'll make it
happen asap!


Cheers,
  HVR

From jmct at jmct.cc  Thu Apr 28 22:36:41 2016
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Thu, 28 Apr 2016 18:36:41 -0400
Subject: Infrastructure & Communication
In-Reply-To: <87pot9ieho.fsf@gmail.com>
References: <87pot9ieho.fsf@gmail.com>
Message-ID: <CAK+ijdsMvkuva46MVziXuTjsLNRLoOATRPnwfSifrh-dvgBfsg@mail.gmail.com>

Hello,

First of all, thanks for all your effort in setting this up!

On Thu, Apr 28, 2016 at 5:56 PM, Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:
>
> However, since Trac has accumulated quite a bit of old content in its
> ticket-tracker over the years, and "Haskell 2020" has been coined a
> reboot. Maybe it wouldn't be such a bad idea to start over at GitHub,
> and consider the Trac instance mostly as a legacy archive of historic
> content.
>
>
> GitHub allows for Git-based workflows, and there's prior art related to
> language design we could steal ideas from, for instance:
>
>  - https://github.com/fsharp/FSharpLangDesign
>  - https://github.com/rust-lang/rfcs
>  - https://github.com/golang/proposal
>  - (any others noteworthy?)
>

This seems like the pragmatic way forward. And, as you say, there's plenty
of evidence from other language communities that it can work effectively.

> IMO, GitHub's issue tracker has become flexible enough for our needs and
> its integration with Git pull-requests allows to e.g. group together
> change proposal description/motivation, discussion, and finaly the delta
> to the haskell-report (with inline annotations/reviews) and so on.
> (However, I consider GitHub's Wiki-component quite weak. I'm not sure
> what to do about that. Maybe keep using Trac's wiki for that?)
>

I personally have no problem with a Trac wiki. That being said, the Rust
model of having an RFC repo seems to have worked really well for them
and allows for easy discussion and comments from the community at large.
If we choose to go that route I would gladly take the time to gather relevant
info from the Trac wiki and organize it similarly to the way the Rust team has.

> Does anyone object to using GitHub?
>

I think it's great.

> In case there's no objection, which of the existing language-design
> GitHub projects do you consider a good fit for Haskell Prime and
> therefore worthy of imitation?
>

I'm a big fan of the Rust model myself.

Thanks again for your effort in getting all this off the ground,

Jose

From takenobu.hs at gmail.com  Thu Apr 28 22:56:16 2016
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Fri, 29 Apr 2016 07:56:16 +0900
Subject: Evaluation order control between two expressions
Message-ID: <CAPB_NvzOXSP4JjF+Jzmd0PSnq+JqH1o25pK=JNYMjie4ABzqmg@mail.gmail.com>

Dear Community,

Apologies if I'm missing context.

Does Haskell 2020 specify evaluation order control by `pseq`?

We use `pseq` to guarantee the evaluation order between two expressions.
But Haskell 2010 did not specify how to control the evaluation order
between two expressions.
(only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't
guarantee the order. [2])

I think it's better to explicitly specify `pseq` as standard way.

Already discussed? or out of scope?

[1]:
https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1260006.2
[2]:
https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens

Regards,
Takenobu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160429/0833c098/attachment.html>

From tomberek at gmail.com  Fri Apr 29 00:47:08 2016
From: tomberek at gmail.com (Thomas Bereknyei)
Date: Thu, 28 Apr 2016 20:47:08 -0400
Subject: Infrastructure and Communication
In-Reply-To: <CA+CkF205BBS048q_ubr=yuiBxQwRHD3i2wVTts6vrFjOfTbuug@mail.gmail.com>
References: <CA+CkF23GZWemfn-EfWtiDKgC=hq=1o=AY8A_32F+XpMxeY4VMA@mail.gmail.com>
 <CA+CkF20k_q9GB=o_D1Qw4B_ZuKCXk=jcfBk6SXRZEAixHAo7AA@mail.gmail.com>
 <CA+CkF21Wqx6SfCBP1zFk5iks4ntLwh44++SrKMEsV2THsewECA@mail.gmail.com>
 <CA+CkF21nHbXHcAT+LMnz9BB3dGmkrSypGfVs-dOa05npjag1nQ@mail.gmail.com>
 <CA+CkF205BBS048q_ubr=yuiBxQwRHD3i2wVTts6vrFjOfTbuug@mail.gmail.com>
Message-ID: <CA+CkF22q-VFmKz0Cykfh0-Nd+igFHOVvMpcOenbw26tyuTYaZg@mail.gmail.com>

I am not on the committee, just a lurker. I find the Golang proposal/design
doc approach amenable to the expected scope of work.

Another benefit of the GitHub approach is greater participation by non
committee members.

Tom

> GitHub allows for Git-based workflows, and there's prior art related to
> language design we could steal ideas from, for instance:
>
>  - https://github.com/fsharp/FSharpLangDesign
>  - https://github.com/rust-lang/rfcs
>  - https://github.com/golang/proposal
>  - (any others noteworthy?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160428/00370183/attachment.html>

From m.farkasdyck at gmail.com  Fri Apr 29 01:51:18 2016
From: m.farkasdyck at gmail.com (M Farkas-Dyck)
Date: Thu, 28 Apr 2016 17:51:18 -0800
Subject: Haskell Prime 2020 committee
In-Reply-To: <CABUjdS7kCVMhd+=vd03zgDcp=gNC1NP18i59XPfi55ZzHE2=Yw@mail.gmail.com>
References: <mailman.15.1461844802.25881.haskell-prime@haskell.org>
 <933456674.4396531.1461862345853.JavaMail.yahoo@mail.yahoo.com>
 <4AA2B94E-A522-4A5D-9A1A-EAD6BED63C40@cis.upenn.edu>
 <7C7D2193-1A41-45EE-82A5-8AFAD749F2D3@lelf.lu>
 <CABUjdS4usWuFW+8k8QDtTv=5_48pzqh8BkJa5pswteteo7D=tA@mail.gmail.com>
 <CAK+ijdv0TfWKq1D1pEcMntditNs67YTVErF631w+2wKNb0so0A@mail.gmail.com>
 <CABUjdS7kCVMhd+=vd03zgDcp=gNC1NP18i59XPfi55ZzHE2=Yw@mail.gmail.com>
Message-ID: <CAL3m8eBGQ=6r_Fjn5a8YiScwBqfUTWc9-ObGLJB1ZNBpVBQ-YQ@mail.gmail.com>

On 28/04/2016, wren romano <wren at community.haskell.org> wrote:
> On Thu, Apr 28, 2016 at 5:19 PM, Jos? Manuel Calder?n Trilla
> <jmct at jmct.cc> wrote:
>> I was able to make an account with a longer username, but I am not
>> able to edit the wiki. Unsure if it's some sort of anti-spam delay or
>> some other issue with permissions.
>
> The issue I had wasn't about the local naming policy, but a
> no-permissions error since I'm not an admin

I can't see any edit links at all.

I'm "strake" on the wiki by the way.

From mail at andres-loeh.de  Fri Apr 29 07:02:05 2016
From: mail at andres-loeh.de (Andres Loeh)
Date: Fri, 29 Apr 2016 09:02:05 +0200
Subject: Infrastructure & Communication
In-Reply-To: <CAK+ijdsMvkuva46MVziXuTjsLNRLoOATRPnwfSifrh-dvgBfsg@mail.gmail.com>
References: <87pot9ieho.fsf@gmail.com>
 <CAK+ijdsMvkuva46MVziXuTjsLNRLoOATRPnwfSifrh-dvgBfsg@mail.gmail.com>
Message-ID: <CALjd_v5dssTpfW0K5jz3Q_xdw0PveG_ao_4=Q6DtnJqZTEX=5Q@mail.gmail.com>

Hi.

I'm ok with the general proposals made by Herbert. I'm not a huge fan
of github myself, but it seems like the most pragmatic choice right
now, and I wouldn't know anything else that is clearly better, so I'm
in favour. I'd somewhat prefer to have everything (wiki etc) in one
place then, but I don't have strong opinions on this topic.

Cheers,
  Andres

From alexander at plaimi.net  Fri Apr 29 09:25:47 2016
From: alexander at plaimi.net (Alexander Berntsen)
Date: Fri, 29 Apr 2016 11:25:47 +0200
Subject: Infrastructure & Communication
In-Reply-To: <CALjd_v5dssTpfW0K5jz3Q_xdw0PveG_ao_4=Q6DtnJqZTEX=5Q@mail.gmail.com>
References: <87pot9ieho.fsf@gmail.com>
 <CAK+ijdsMvkuva46MVziXuTjsLNRLoOATRPnwfSifrh-dvgBfsg@mail.gmail.com>
 <CALjd_v5dssTpfW0K5jz3Q_xdw0PveG_ao_4=Q6DtnJqZTEX=5Q@mail.gmail.com>
Message-ID: <5723289B.8040000@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 29/04/16 09:02, Andres Loeh wrote:
> I'm not a huge fan of github myself, but it seems like the most
> pragmatic choice right now, and I wouldn't know anything else that
> is clearly better, so I'm in favour. I'd somewhat prefer to have
> everything (wiki etc) in one place then, but I don't have strong
> opinions on this topic.
I'm not on the committee, but I would suggest having everything
available from haskell.org. I'm in general not fond of free software
projects relying on proprietary software; especially not SaaSS which
theoretically can just get rid of all your data without you having a
say. As such, I would recommend at least synchronising or snapshotting
things to haskell.org infrastructure.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXIyiaAAoJENQqWdRUGk8Bo3kQAIjKgP3oyhR78O5u6x1Jjadr
+QBuSrOaB3tTqBfnocoGR5pBPiIeSXRfGUi6lQnLrT54pkr+z/0U/GLp7HCY1RtL
oJjJt4Y1CGt0i9bSah93Uw2eupp08crlIQaGBZ+JgYFkQdxRU2GK8KpW/sn0lUnk
bUI1l9egIYIz48YEaKx5qs4Bp7XNeD7mqBLP/FhmwD86GxcULws408GLf8sS6mN2
S/4qg0vtj0YCKDNrg6VdzV2eUfo+0QNShT54+3pOWlXgdxn3/JcEmxpLKCPsuwdl
3r86SJWsA+QRfLTbyBKsbBydOiF/VZlCe1xIi2zHwEojWGUyprkV7G6J2vBcPmEy
rMW4Vp4AcsqxbvOXyJSqm6f7vTpEGkepM1YcgyNRqs0GRKRaivIwStw2V3nDIl78
2tc7xEURlcoewy/RqE41MLH3zHXjZ/6fd+UYOU/mV2hktjysC67nQ2v+zEJ3MY6A
N090PGMI3kamd0ByyzSwkwJ4sgj5FH5+AxtJ2Eb7YN/kAw9jnGauusTpF54P83ia
t+fFEgUkdYz7bFHKYXD3MvD33jh+f2rmWo9Ow0cxI5JS+5TrwyIDBjHD6dJf4KuJ
AV6/abZJ2VZ7nJxjWPUXz2kYwmKfarQFWL+LXwhaV3xHASld1HhJeS22TpdmFY2p
UcRFHbFuzpSeSeWHOnDg
=eClD
-----END PGP SIGNATURE-----

From audreyt at audreyt.org  Fri Apr 29 11:17:27 2016
From: audreyt at audreyt.org (Audrey Tang)
Date: Fri, 29 Apr 2016 19:17:27 +0800
Subject: Infrastructure & Communication
In-Reply-To: <5723289B.8040000@plaimi.net>
References: <87pot9ieho.fsf@gmail.com>
 <CAK+ijdsMvkuva46MVziXuTjsLNRLoOATRPnwfSifrh-dvgBfsg@mail.gmail.com>
 <CALjd_v5dssTpfW0K5jz3Q_xdw0PveG_ao_4=Q6DtnJqZTEX=5Q@mail.gmail.com>
 <5723289B.8040000@plaimi.net>
Message-ID: <FA32195D-3371-487E-8D57-BD11838D1467@audreyt.org>

> On Apr 29, 2016, at 5:25 PM, Alexander Berntsen <alexander at plaimi.net> wrote:
> especially not SaaSS which theoretically can just get rid of all your data without you having a say.

There is a fix for that ? Sandstorm.io <https://sandstorm.io/> (self-hosted, not SaaSS) with download-all-data-at-any-time options such as Gogs on Sandstorm <https://apps.sandstorm.io/app/d9ygf47xrtnw12j92cyt6cu8ut75esx01u4q3kcrn8415w9qzzgh>. 

Personally I use it as a secondary storage to public github repositories, and primary storage for personal projects.

Cheers,
Audrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160429/b4a7c1b5/attachment-0001.html>

From fa-ml at ariis.it  Fri Apr 29 11:15:40 2016
From: fa-ml at ariis.it (Francesco Ariis)
Date: Fri, 29 Apr 2016 13:15:40 +0200
Subject: Infrastructure & Communication
In-Reply-To: <87pot9ieho.fsf@gmail.com>
References: <87pot9ieho.fsf@gmail.com>
Message-ID: <20160429111540.GA22682@casa.casa>

On Thu, Apr 28, 2016 at 11:56:51PM +0200, Herbert Valerio Riedel wrote:
> One benefit I see from using GitHub is that this way would we be closer
> to the Haskell community (given the majority of Hackage packages are
> hosted on GitHub), and our work would be more transparent for the
> community as well as offering a lower barrier to
> participation/contribution.
> 
> Moreover, I think GitHub would also help make our efforts/progress
> towards a revised Haskell Report more visible to the community, which in
> turn may even provide us the motivation to carry on...

Hello,
    personally I would be more likely to read/participate in the
discussions if such discussions were hosted here or on Trac rather
than Github.
haskell-prime@ is just one 'subscribe' away, comes in a familiar package
to haskell-cafe@ participants (a mailing list) and interface (their mail
client); I cannot say the same about Github.
Similarly, Trac allows me to follow new issues (new tickets notifications
or the life of a single ticket in particular) via rss, without having to
register to a new service.

Of course:
    1. this is just my experience -- there are many haskell
       developers on Github and they probably like the workflow
       there (I would still say the haskell-cafe@ audience is bigger
       though).
    2. I am not a committee member. In the end it's them who are going
       to pour blood/sweat/tears in the report; whichever tool the
       committee chooses is the right one

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160429/bb6b442b/attachment.sig>

From carter.schonwald at gmail.com  Fri Apr 29 12:44:53 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 29 Apr 2016 08:44:53 -0400
Subject: Infrastructure & Communication
In-Reply-To: <20160429111540.GA22682@casa.casa>
References: <87pot9ieho.fsf@gmail.com>
	<20160429111540.GA22682@casa.casa>
Message-ID: <CAHYVw0z9b1fz6OGnsFBfKrX1PY1UwoEodki2SOKNO548POuODQ@mail.gmail.com>

Or a phabricator instance ? That might also make sense.

On Friday, April 29, 2016, Francesco Ariis <fa-ml at ariis.it> wrote:

> On Thu, Apr 28, 2016 at 11:56:51PM +0200, Herbert Valerio Riedel wrote:
> > One benefit I see from using GitHub is that this way would we be closer
> > to the Haskell community (given the majority of Hackage packages are
> > hosted on GitHub), and our work would be more transparent for the
> > community as well as offering a lower barrier to
> > participation/contribution.
> >
> > Moreover, I think GitHub would also help make our efforts/progress
> > towards a revised Haskell Report more visible to the community, which in
> > turn may even provide us the motivation to carry on...
>
> Hello,
>     personally I would be more likely to read/participate in the
> discussions if such discussions were hosted here or on Trac rather
> than Github.
> haskell-prime@ is just one 'subscribe' away, comes in a familiar package
> to haskell-cafe@ participants (a mailing list) and interface (their mail
> client); I cannot say the same about Github.
> Similarly, Trac allows me to follow new issues (new tickets notifications
> or the life of a single ticket in particular) via rss, without having to
> register to a new service.
>
> Of course:
>     1. this is just my experience -- there are many haskell
>        developers on Github and they probably like the workflow
>        there (I would still say the haskell-cafe@ audience is bigger
>        though).
>     2. I am not a committee member. In the end it's them who are going
>        to pour blood/sweat/tears in the report; whichever tool the
>        committee chooses is the right one
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160429/41ff2536/attachment.html>

From blamario at ciktel.net  Fri Apr 29 13:17:21 2016
From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Fri, 29 Apr 2016 09:17:21 -0400
Subject: Infrastructure & Communication
In-Reply-To: <20160429111540.GA22682@casa.casa>
References: <87pot9ieho.fsf@gmail.com> <20160429111540.GA22682@casa.casa>
Message-ID: <57235EE1.80203@ciktel.net>

On 04/29/2016 07:15 AM, Francesco Ariis wrote:
> Hello,
>      personally I would be more likely to read/participate in the
> discussions if such discussions were hosted here or on Trac rather
> than Github.

     There are two or three distinct components we need to keep track 
of: the draft standard, discussions, and potentially RFCs.

     Discussions can be hosted on this mailing list, on Trac, or as Git 
issues. Each of them would serve fine, but we should choose exactly one 
and stick to it. The mailing list looks pretty good in isolation, but 
the best choice depends on whether we want to have RFCs or not.

     If we support Requests for Comments, we'll need to also support 
their public submissions and Git pull requests or something to the same 
effect. In that case, at least the inevitable comments on RFCs would 
best be placed close to the RFCs themselves - if the RFCs end up on 
GitHub the discussions of them should be kept as GitHub issues.


From eir at cis.upenn.edu  Fri Apr 29 13:17:43 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 29 Apr 2016 09:17:43 -0400
Subject: Chairship / responsibility
Message-ID: <83F0C468-66F5-4B3F-9337-D3A3B4D229DC@cis.upenn.edu>

Hi Prime,

Is there a chair of this committee? Herbert has been acting as such (thank you!) but doesn't list himself as the chair in the initial announcement. I am **in no way** trying to change any status quo and am **not** interested in being chair at the moment, but I just wanted to clarify.

The specific reason I ask is that Takenobu Tani recently asked about `pseq`. I have no intelligent response to offer, but would want to make sure that someone does offer a response. If there is a chair, that person is de facto responsible that we, as a committee, communicate well, both internally and externally.

Thanks,
Richard

From eir at cis.upenn.edu  Fri Apr 29 13:22:23 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 29 Apr 2016 09:22:23 -0400
Subject: Infrastructure & Communication
In-Reply-To: <57235EE1.80203@ciktel.net>
References: <87pot9ieho.fsf@gmail.com> <20160429111540.GA22682@casa.casa>
 <57235EE1.80203@ciktel.net>
Message-ID: <017C59B8-C04B-4B43-A384-73BBFB5CE0BB@cis.upenn.edu>

I think the general interplay between mailing lists / wiki pages / Trac issues that GHC uses works well. Specifically:

- Mailing list for routine communication.
- Trac tickets / Git issues / Phab something-or-other for discussion on a specific proposal.
- Wiki page to present a specific proposal.

Wiki pages and tickets are therefore often linked together, and sometimes a conversation has to move from the mailing list to a ticket (though rarely the other way around).

I specifically vote against using the mailing list to debate well-defined issues that need to be resolved, as it's far too easy to lose signal in the noise and hard to see the thread all in one place.

I'm personally agnostic about the decision between Trac/Github/Phab.

Richard

On Apr 29, 2016, at 9:17 AM, Mario Bla?evi? <blamario at ciktel.net> wrote:

> On 04/29/2016 07:15 AM, Francesco Ariis wrote:
>> Hello,
>>     personally I would be more likely to read/participate in the
>> discussions if such discussions were hosted here or on Trac rather
>> than Github.
> 
>    There are two or three distinct components we need to keep track of: the draft standard, discussions, and potentially RFCs.
> 
>    Discussions can be hosted on this mailing list, on Trac, or as Git issues. Each of them would serve fine, but we should choose exactly one and stick to it. The mailing list looks pretty good in isolation, but the best choice depends on whether we want to have RFCs or not.
> 
>    If we support Requests for Comments, we'll need to also support their public submissions and Git pull requests or something to the same effect. In that case, at least the inevitable comments on RFCs would best be placed close to the RFCs themselves - if the RFCs end up on GitHub the discussions of them should be kept as GitHub issues.
> 
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


From mblazevic at stilo.com  Fri Apr 29 15:37:05 2016
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Fri, 29 Apr 2016 11:37:05 -0400
Subject: Infrastructure & Communication
In-Reply-To: <017C59B8-C04B-4B43-A384-73BBFB5CE0BB@cis.upenn.edu>
References: <87pot9ieho.fsf@gmail.com> <20160429111540.GA22682@casa.casa>
 <57235EE1.80203@ciktel.net>
 <017C59B8-C04B-4B43-A384-73BBFB5CE0BB@cis.upenn.edu>
Message-ID: <57237FA1.6000100@stilo.com>

On 16-04-29 09:22 AM, Richard Eisenberg wrote:
> I think the general interplay between mailing lists / wiki pages /
> Trac issues that GHC uses works well. Specifically:
>
> - Mailing list for routine communication.
> - Trac tickets / Git issues / Phab something-or-other for discussion on a specific proposal.
> - Wiki page to present a specific proposal.
>
> Wiki pages and tickets are therefore often linked together, and
> sometimes a conversation has to move from the mailing list to a
> ticket (though rarely the other way around).
>
> I specifically vote against using the mailing list to debate
> well-defined issues that need to be resolved, as it's far too easy to
> lose signal in the noise and hard to see the thread all in one
> place.

	I fully agree with this point. I also agree that this particular 
discussion is in happening the right venue.


>
> I'm personally agnostic about the decision between Trac/Github/Phab.
>

	I'm leaning toward GitHub for RFCs myself, mainly because of the fork & 
pull request paradigm. Collaborative Wiki editing doesn't have such a 
clear division of responsibilities.

	The main question is, do we want the RFCs as part of the process, or 
just the draft standard and discussions thereof?

From jmct at jmct.cc  Fri Apr 29 21:38:39 2016
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Fri, 29 Apr 2016 17:38:39 -0400
Subject: Evaluation order control between two expressions
In-Reply-To: <CAPB_NvzOXSP4JjF+Jzmd0PSnq+JqH1o25pK=JNYMjie4ABzqmg@mail.gmail.com>
References: <CAPB_NvzOXSP4JjF+Jzmd0PSnq+JqH1o25pK=JNYMjie4ABzqmg@mail.gmail.com>
Message-ID: <CAK+ijdvsH2O6jtv2E_j1QtvXeqfgaQ=rLScZc0iv_0jtW1khnw@mail.gmail.com>

Hello Takenobu,

Great question, this is actually a pretty interesting issue! It isn't
out of scope at all.

The first thing to think about is the following thought experiment:

Without the presence of side-effects, how can you tell the difference
between a `seq` that conforms to the Haskell report and one that
evaluates it's first argument before its second?

If your answer involves `unsafePerformIO` then you're cheating ;)

Even if your first argument to `seq` is an IO action it won't get
executed because `seq` only evaluates to WHNF. It might be possible to
construct a program that allows you to observe the difference, but in
the general case I don't see how you could. I'd be very interested to
be shown otherwise though!

Now in a parallel program things change. When we use `pseq` it's
because we don't want two threads to collide when trying to evaluate
the same expression. Let's look at an example:

x `par` y `seq` x + y

As you noted, the semantics of `seq` doesn't actually guarantee that
`y` will be evaluated before `x + y`. But this only matters because
we've used `par` and introduced threads (via an effect!) and therefore
the possibility of collision. We can avoid this by using `pseq`
instead.

So, both `seq` and `pseq` both allow the programmer to express
*operational* concerns, `seq` is used mostly to eliminate/manage space
leaks, and `pseq` is used to specify order of evaluation. Those
concerns sometimes overlap, but they are different!

It could be argued (and I would agree) that `seq` is a bad name; a
better name might have been something like `synch` [1]. That being
said, unless we add parallelism to the standard (and even then) I am
not sure it would be wise to change the operational behavior of `seq`.
It's current behavior is well established, and if you're writing
sequential Haskell code where order of evaluation matters, it's
probably better to reach for a different tool (IMO). However, if
parallelism is introduced then I'd fight for `pseq` to be part of that
(as you suggest).

I hope that sheds some light on the issue.

Cheers,

Jose

[1]: John Hughes introduced a `synch` combinator in his thesis, but it
had very different semantics, so maybe that's a reason it was avoided?
Someone with more knowledge of the history can probably shed more
light on this.


On Thu, Apr 28, 2016 at 6:56 PM, Takenobu Tani <takenobu.hs at gmail.com> wrote:
> Dear Community,
>
> Apologies if I'm missing context.
>
> Does Haskell 2020 specify evaluation order control by `pseq`?
>
> We use `pseq` to guarantee the evaluation order between two expressions.
> But Haskell 2010 did not specify how to control the evaluation order between
> two expressions.
> (only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't
> guarantee the order. [2])
>
> I think it's better to explicitly specify `pseq` as standard way.
>
> Already discussed? or out of scope?
>
> [1]:
> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1260006.2
> [2]:
> https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens
>
> Regards,
> Takenobu
>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>

From cgibbard at gmail.com  Fri Apr 29 23:17:36 2016
From: cgibbard at gmail.com (Cale Gibbard)
Date: Fri, 29 Apr 2016 19:17:36 -0400
Subject: Evaluation order control between two expressions
In-Reply-To: <CAK+ijdvsH2O6jtv2E_j1QtvXeqfgaQ=rLScZc0iv_0jtW1khnw@mail.gmail.com>
References: <CAPB_NvzOXSP4JjF+Jzmd0PSnq+JqH1o25pK=JNYMjie4ABzqmg@mail.gmail.com>
 <CAK+ijdvsH2O6jtv2E_j1QtvXeqfgaQ=rLScZc0iv_0jtW1khnw@mail.gmail.com>
Message-ID: <CAF3RzK8mqRBPzstnS_G_kCZcH9up6hbu7wZBR9B9--TRHBhLJA@mail.gmail.com>

Well, the value of par x y is identical to that of y, so any expression
which you could use to semantically distinguish pseq from seq using par
could be rewritten into one which did so without involving par.

If the way in which we're telling programs apart involves performance
characteristics then it may already be possible to distinguish seq from
pseq. It somewhat comes down to whether the implementation of the language
is clever enough to notice when compiling seq x y any cases where it might
be better to finish evaluating y first and simply evaluate x before making
the result of that first evaluation available. GHC does do this
rearranging, so probably someone can come up with a good example there.
On Apr 29, 2016 5:38 PM, "Jos? Manuel Calder?n Trilla" <jmct at jmct.cc> wrote:

> Hello Takenobu,
>
> Great question, this is actually a pretty interesting issue! It isn't
> out of scope at all.
>
> The first thing to think about is the following thought experiment:
>
> Without the presence of side-effects, how can you tell the difference
> between a `seq` that conforms to the Haskell report and one that
> evaluates it's first argument before its second?
>
> If your answer involves `unsafePerformIO` then you're cheating ;)
>
> Even if your first argument to `seq` is an IO action it won't get
> executed because `seq` only evaluates to WHNF. It might be possible to
> construct a program that allows you to observe the difference, but in
> the general case I don't see how you could. I'd be very interested to
> be shown otherwise though!
>
> Now in a parallel program things change. When we use `pseq` it's
> because we don't want two threads to collide when trying to evaluate
> the same expression. Let's look at an example:
>
> x `par` y `seq` x + y
>
> As you noted, the semantics of `seq` doesn't actually guarantee that
> `y` will be evaluated before `x + y`. But this only matters because
> we've used `par` and introduced threads (via an effect!) and therefore
> the possibility of collision. We can avoid this by using `pseq`
> instead.
>
> So, both `seq` and `pseq` both allow the programmer to express
> *operational* concerns, `seq` is used mostly to eliminate/manage space
> leaks, and `pseq` is used to specify order of evaluation. Those
> concerns sometimes overlap, but they are different!
>
> It could be argued (and I would agree) that `seq` is a bad name; a
> better name might have been something like `synch` [1]. That being
> said, unless we add parallelism to the standard (and even then) I am
> not sure it would be wise to change the operational behavior of `seq`.
> It's current behavior is well established, and if you're writing
> sequential Haskell code where order of evaluation matters, it's
> probably better to reach for a different tool (IMO). However, if
> parallelism is introduced then I'd fight for `pseq` to be part of that
> (as you suggest).
>
> I hope that sheds some light on the issue.
>
> Cheers,
>
> Jose
>
> [1]: John Hughes introduced a `synch` combinator in his thesis, but it
> had very different semantics, so maybe that's a reason it was avoided?
> Someone with more knowledge of the history can probably shed more
> light on this.
>
>
> On Thu, Apr 28, 2016 at 6:56 PM, Takenobu Tani <takenobu.hs at gmail.com>
> wrote:
> > Dear Community,
> >
> > Apologies if I'm missing context.
> >
> > Does Haskell 2020 specify evaluation order control by `pseq`?
> >
> > We use `pseq` to guarantee the evaluation order between two expressions.
> > But Haskell 2010 did not specify how to control the evaluation order
> between
> > two expressions.
> > (only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't
> > guarantee the order. [2])
> >
> > I think it's better to explicitly specify `pseq` as standard way.
> >
> > Already discussed? or out of scope?
> >
> > [1]:
> >
> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1260006.2
> > [2]:
> >
> https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens
> >
> > Regards,
> > Takenobu
> >
> >
> > _______________________________________________
> > Haskell-prime mailing list
> > Haskell-prime at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> >
> _______________________________________________
> 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/20160429/325cd492/attachment-0001.html>

From wren at community.haskell.org  Sat Apr 30 02:49:33 2016
From: wren at community.haskell.org (wren romano)
Date: Fri, 29 Apr 2016 22:49:33 -0400
Subject: Infrastructure & Communication
In-Reply-To: <57235EE1.80203@ciktel.net>
References: <87pot9ieho.fsf@gmail.com> <20160429111540.GA22682@casa.casa>
 <57235EE1.80203@ciktel.net>
Message-ID: <CABUjdS6ciar24nUVx=rvqwFQgmEZYuOpps8Tua_O_TQmMJWBuQ@mail.gmail.com>

On Fri, Apr 29, 2016 at 9:17 AM, Mario Bla?evi? <blamario at ciktel.net> wrote:
>     There are two or three distinct components we need to keep track of: the
> draft standard, discussions, and potentially RFCs.
>
>     Discussions can be hosted on this mailing list, on Trac, or as Git
> issues. Each of them would serve fine, but we should choose exactly one and
> stick to it. The mailing list looks pretty good in isolation, but the best
> choice depends on whether we want to have RFCs or not.
>
>     If we support Requests for Comments, we'll need to also support their
> public submissions and Git pull requests or something to the same effect. In
> that case, at least the inevitable comments on RFCs would best be placed
> close to the RFCs themselves - if the RFCs end up on GitHub the discussions
> of them should be kept as GitHub issues.

I agree with all of this, and think this distinction should be kept in
mind in terms of keeping things organized to whatever tools we choose.

For general discussions I think this mailing list is best. I'm cool
for keeping irc as a side channel for hashing things out more
interactively, but it's all to easy to miss things there so I think
it's best kept as a side channel not a main one.

I like (something like) GitHub issues for tracking the exact content
of proposed changes and their (direct) commentary. As far as the
particular tool I'm mostly agnostic, but lean slightly towards github
over trac. I've never used phabricator so can't say there (though I'm
slightly against, as it'd be another tool to learn.)

As far as wiki stuff goes, to be honest I'm kinda against it. I see
how it might could be helpful as a sort of staging ground prior to
actual RFCs, or as an edited synopsis of email discussion; but in my
experience the wiki proposals for Haskell changes tend to get very
crufty and hard to follow after a few changes have been made. I think
I'd rather see specific versioning on proposals, so it can be clear
when/which parts of the proposal are retracted, amended, etc. This may
very well be a reason to prefer github, since such development can
happen in branches where we can see the iteration of changes prior to
merging a specific one into the master branch.

/me goes off to read about how Fsharp, Rust, and Go do things

-- 
Live well,
~wren

From wren at community.haskell.org  Sat Apr 30 02:51:22 2016
From: wren at community.haskell.org (wren romano)
Date: Fri, 29 Apr 2016 22:51:22 -0400
Subject: Chairship / responsibility
In-Reply-To: <CABUjdS4DpVA+L6Ubbf5yXMoCFLZ+kDS5eyWhTK8a_YQM=xVT0w@mail.gmail.com>
References: <83F0C468-66F5-4B3F-9337-D3A3B4D229DC@cis.upenn.edu>
 <CABUjdS4DpVA+L6Ubbf5yXMoCFLZ+kDS5eyWhTK8a_YQM=xVT0w@mail.gmail.com>
Message-ID: <CABUjdS5KgSt-a_pOiKRAWoCTRhOst=NW1bc2JJ7YfPdKUuh-Nw@mail.gmail.com>

> Hi Prime,
>
> Is there a chair of this committee? Herbert has been acting as such (thank you!) but doesn't list himself as the chair in the initial announcement. I am **in no way** trying to change any status quo and am **not** interested in being chair at the moment, but I just wanted to clarify.
>
> The specific reason I ask is that Takenobu Tani recently asked about `pseq`. I have no intelligent response to offer, but would want to make sure that someone does offer a response. If there is a chair, that person is de facto responsible that we, as a committee, communicate well, both internally and externally.


I don't know that we have one (officially), but I agree that
getting/agreeing-on one should be done soon.

-- 
Live well,
~wren

From gershomb at gmail.com  Sat Apr 30 04:31:10 2016
From: gershomb at gmail.com (Gershom B)
Date: Sat, 30 Apr 2016 00:31:10 -0400
Subject: Infrastructure & Communication
In-Reply-To: <CABUjdS6ciar24nUVx=rvqwFQgmEZYuOpps8Tua_O_TQmMJWBuQ@mail.gmail.com>
References: <87pot9ieho.fsf@gmail.com> <20160429111540.GA22682@casa.casa>
 <57235EE1.80203@ciktel.net>
 <CABUjdS6ciar24nUVx=rvqwFQgmEZYuOpps8Tua_O_TQmMJWBuQ@mail.gmail.com>
Message-ID: <etPan.5724354e.3a964cf9.14c@mbp.local>

On April 29, 2016 at 10:49:38 PM, wren romano (wren at community.haskell.org) wrote:
>  
> I like (something like) GitHub issues for tracking the exact content
> of proposed changes and their (direct) commentary. As far as the
> particular tool I'm mostly agnostic, but lean slightly towards github
> over trac. I've never used phabricator so can't say there (though I'm
> slightly against, as it'd be another tool to learn.)
>

If github makes sense but there is a concern over a permanent record that is not in the custody solely of a private company, then there is a nice tool (in haskell no less) that will pull the various associated data of a repo (including issues) into a branch in the repo itself [1].

We could then script a regular pull of the repo into some common haskell community infrastructure.

Cheers,
Gershom

[1]?https://github.com/joeyh/github-backup

From takenobu.hs at gmail.com  Sat Apr 30 07:11:09 2016
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Sat, 30 Apr 2016 16:11:09 +0900
Subject: Evaluation order control between two expressions
In-Reply-To: <CAF3RzK8mqRBPzstnS_G_kCZcH9up6hbu7wZBR9B9--TRHBhLJA@mail.gmail.com>
References: <CAPB_NvzOXSP4JjF+Jzmd0PSnq+JqH1o25pK=JNYMjie4ABzqmg@mail.gmail.com>
 <CAK+ijdvsH2O6jtv2E_j1QtvXeqfgaQ=rLScZc0iv_0jtW1khnw@mail.gmail.com>
 <CAF3RzK8mqRBPzstnS_G_kCZcH9up6hbu7wZBR9B9--TRHBhLJA@mail.gmail.com>
Message-ID: <CAPB_NvxDv5bsDTyDRHDk-L5RcpCD9y+_3kd2k_YHcp-1WexBtQ@mail.gmail.com>

Hi Jose and Cale,

Thank you for clear and detailed explanation.

short summary:

 * `seq`  used to eliminate/manage space leaks
 * `pseq` used to specify order of evaluation

 * `seq` is a bad name, but well established.
 * If we introduce parallelism to standard, we need `pseq` or some method.


It's depending on whether or not corresponding to the parallelism.
I learned a lot. Thank you very much.

Regards,
Takenobu

2016-04-30 8:17 GMT+09:00 Cale Gibbard <cgibbard at gmail.com>:

> Well, the value of par x y is identical to that of y, so any expression
> which you could use to semantically distinguish pseq from seq using par
> could be rewritten into one which did so without involving par.
>
> If the way in which we're telling programs apart involves performance
> characteristics then it may already be possible to distinguish seq from
> pseq. It somewhat comes down to whether the implementation of the language
> is clever enough to notice when compiling seq x y any cases where it might
> be better to finish evaluating y first and simply evaluate x before making
> the result of that first evaluation available. GHC does do this
> rearranging, so probably someone can come up with a good example there.
> On Apr 29, 2016 5:38 PM, "Jos? Manuel Calder?n Trilla" <jmct at jmct.cc>
> wrote:
>
>> Hello Takenobu,
>>
>> Great question, this is actually a pretty interesting issue! It isn't
>> out of scope at all.
>>
>> The first thing to think about is the following thought experiment:
>>
>> Without the presence of side-effects, how can you tell the difference
>> between a `seq` that conforms to the Haskell report and one that
>> evaluates it's first argument before its second?
>>
>> If your answer involves `unsafePerformIO` then you're cheating ;)
>>
>> Even if your first argument to `seq` is an IO action it won't get
>> executed because `seq` only evaluates to WHNF. It might be possible to
>> construct a program that allows you to observe the difference, but in
>> the general case I don't see how you could. I'd be very interested to
>> be shown otherwise though!
>>
>> Now in a parallel program things change. When we use `pseq` it's
>> because we don't want two threads to collide when trying to evaluate
>> the same expression. Let's look at an example:
>>
>> x `par` y `seq` x + y
>>
>> As you noted, the semantics of `seq` doesn't actually guarantee that
>> `y` will be evaluated before `x + y`. But this only matters because
>> we've used `par` and introduced threads (via an effect!) and therefore
>> the possibility of collision. We can avoid this by using `pseq`
>> instead.
>>
>> So, both `seq` and `pseq` both allow the programmer to express
>> *operational* concerns, `seq` is used mostly to eliminate/manage space
>> leaks, and `pseq` is used to specify order of evaluation. Those
>> concerns sometimes overlap, but they are different!
>>
>> It could be argued (and I would agree) that `seq` is a bad name; a
>> better name might have been something like `synch` [1]. That being
>> said, unless we add parallelism to the standard (and even then) I am
>> not sure it would be wise to change the operational behavior of `seq`.
>> It's current behavior is well established, and if you're writing
>> sequential Haskell code where order of evaluation matters, it's
>> probably better to reach for a different tool (IMO). However, if
>> parallelism is introduced then I'd fight for `pseq` to be part of that
>> (as you suggest).
>>
>> I hope that sheds some light on the issue.
>>
>> Cheers,
>>
>> Jose
>>
>> [1]: John Hughes introduced a `synch` combinator in his thesis, but it
>> had very different semantics, so maybe that's a reason it was avoided?
>> Someone with more knowledge of the history can probably shed more
>> light on this.
>>
>>
>> On Thu, Apr 28, 2016 at 6:56 PM, Takenobu Tani <takenobu.hs at gmail.com>
>> wrote:
>> > Dear Community,
>> >
>> > Apologies if I'm missing context.
>> >
>> > Does Haskell 2020 specify evaluation order control by `pseq`?
>> >
>> > We use `pseq` to guarantee the evaluation order between two expressions.
>> > But Haskell 2010 did not specify how to control the evaluation order
>> between
>> > two expressions.
>> > (only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't
>> > guarantee the order. [2])
>> >
>> > I think it's better to explicitly specify `pseq` as standard way.
>> >
>> > Already discussed? or out of scope?
>> >
>> > [1]:
>> >
>> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1260006.2
>> > [2]:
>> >
>> https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens
>> >
>> > Regards,
>> > Takenobu
>> >
>> >
>> > _______________________________________________
>> > Haskell-prime mailing list
>> > Haskell-prime at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>> >
>> _______________________________________________
>> 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/20160430/a2d0a219/attachment.html>

From hvriedel at gmail.com  Sat Apr 30 08:03:55 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sat, 30 Apr 2016 10:03:55 +0200
Subject: Chairship / responsibility
In-Reply-To: <83F0C468-66F5-4B3F-9337-D3A3B4D229DC@cis.upenn.edu> (Richard
 Eisenberg's message of "Fri, 29 Apr 2016 09:17:43 -0400")
References: <83F0C468-66F5-4B3F-9337-D3A3B4D229DC@cis.upenn.edu>
Message-ID: <8760uzmsk4.fsf@gmail.com>

Hello *,

On 2016-04-29 at 15:17:43 +0200, Richard Eisenberg wrote:
> Is there a chair of this committee? Herbert has been acting as such
> (thank you!) but doesn't list himself as the chair in the initial
> announcement.
>
> I am **in no way** trying to change any status quo and
> am **not** interested in being chair at the moment, but I just wanted
> to clarify.

Fwiw, I mentioned in the preceding CfN
(https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html)
that

| In consultation with the current members of the Haskell Prime
| committee (and Simon PJ), I have volunteered as chair to "reboot" the
| process and get things rolling again.

But you're right I failed to repeat this in the actual announcement.

However, I don't want to impose myself on the committee as chair. So if
anyone else feels motivated enough to pick up the role as chair with the
agreement of the committee I'll happily hand over the chair position!
:-)

Moreover, this doesn't need to be a static configuration: We could also
rotate the chair position (and other duties) over the lifetime of the
Haskell 2020 committee. There just needs to be one designated chair at
any time to keep things moving.

> The specific reason I ask is that Takenobu Tani recently asked about
> `pseq`. I have no intelligent response to offer, but would want to
> make sure that someone does offer a response. If there is a chair,
> that person is de facto responsible that we, as a committee,
> communicate well, both internally and externally.

You're definitely right. And IMO the chair only needs to step in if
nobody else feels compelled to respond within a reasonable time, e.g. a
few days -- after all, we all have other duties besides the prime
committee :-)

-- hvr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160430/7398677e/attachment-0001.sig>

From andres.loeh at googlemail.com  Sat Apr 30 08:38:53 2016
From: andres.loeh at googlemail.com (=?UTF-8?Q?Andres_L=C3=B6h?=)
Date: Sat, 30 Apr 2016 10:38:53 +0200
Subject: Chairship / responsibility
In-Reply-To: <8760uzmsk4.fsf@gmail.com>
References: <83F0C468-66F5-4B3F-9337-D3A3B4D229DC@cis.upenn.edu>
 <8760uzmsk4.fsf@gmail.com>
Message-ID: <CALjd_v5aUM08qJNjHjA568cjuNxshmvNeKWRTZQOo4+eYmBs8g@mail.gmail.com>

Hi.

It was my understanding that Herbert would be the chair when I asked
to be on the committee, and the fact that this question was already
answer was a factor in my decision to try to help. Being the committee
chair is less a position of power, and more a position of
responsibility. I think we can be very happy to have someone who is
willing to do the job, and I absolutely trust hvr to be up to the
task.

If needed, we can revisit the question over time when we have a better
idea how our usual workflow and processes look like, but I don't think
we need to or should have this discussion now.

Cheers,
  Andres


On Sat, Apr 30, 2016 at 10:03 AM, Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:
> Hello *,
>
> On 2016-04-29 at 15:17:43 +0200, Richard Eisenberg wrote:
>> Is there a chair of this committee? Herbert has been acting as such
>> (thank you!) but doesn't list himself as the chair in the initial
>> announcement.
>>
>> I am **in no way** trying to change any status quo and
>> am **not** interested in being chair at the moment, but I just wanted
>> to clarify.
>
> Fwiw, I mentioned in the preceding CfN
> (https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html)
> that
>
> | In consultation with the current members of the Haskell Prime
> | committee (and Simon PJ), I have volunteered as chair to "reboot" the
> | process and get things rolling again.
>
> But you're right I failed to repeat this in the actual announcement.
>
> However, I don't want to impose myself on the committee as chair. So if
> anyone else feels motivated enough to pick up the role as chair with the
> agreement of the committee I'll happily hand over the chair position!
> :-)
>
> Moreover, this doesn't need to be a static configuration: We could also
> rotate the chair position (and other duties) over the lifetime of the
> Haskell 2020 committee. There just needs to be one designated chair at
> any time to keep things moving.
>
>> The specific reason I ask is that Takenobu Tani recently asked about
>> `pseq`. I have no intelligent response to offer, but would want to
>> make sure that someone does offer a response. If there is a chair,
>> that person is de facto responsible that we, as a committee,
>> communicate well, both internally and externally.
>
> You're definitely right. And IMO the chair only needs to step in if
> nobody else feels compelled to respond within a reasonable time, e.g. a
> few days -- after all, we all have other duties besides the prime
> committee :-)
>
> -- hvr
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>

From lennart at augustsson.net  Sat Apr 30 10:11:14 2016
From: lennart at augustsson.net (Lennart Augustsson)
Date: Sat, 30 Apr 2016 12:11:14 +0200
Subject: Evaluation order control between two expressions
In-Reply-To: <CAK+ijdvsH2O6jtv2E_j1QtvXeqfgaQ=rLScZc0iv_0jtW1khnw@mail.gmail.com>
References: <CAPB_NvzOXSP4JjF+Jzmd0PSnq+JqH1o25pK=JNYMjie4ABzqmg@mail.gmail.com>
 <CAK+ijdvsH2O6jtv2E_j1QtvXeqfgaQ=rLScZc0iv_0jtW1khnw@mail.gmail.com>
Message-ID: <CAJogeqfGGe4Cg3brfWsY1uJzVV6Kv+UR30xjmmgqQCm8_RP+-w@mail.gmail.com>

Order of evaluation can be very important for memory use.  So I can imagine
cases where seq would run out of memory, but pseq would not.

I would argue that pseq is almost always what you want, but seq has a nicer
denotational semantics.

  -- Lennart

On Friday, April 29, 2016, Jos? Manuel Calder?n Trilla <jmct at jmct.cc> wrote:

> Hello Takenobu,
>
> Great question, this is actually a pretty interesting issue! It isn't
> out of scope at all.
>
> The first thing to think about is the following thought experiment:
>
> Without the presence of side-effects, how can you tell the difference
> between a `seq` that conforms to the Haskell report and one that
> evaluates it's first argument before its second?
>
> If your answer involves `unsafePerformIO` then you're cheating ;)
>
> Even if your first argument to `seq` is an IO action it won't get
> executed because `seq` only evaluates to WHNF. It might be possible to
> construct a program that allows you to observe the difference, but in
> the general case I don't see how you could. I'd be very interested to
> be shown otherwise though!
>
> Now in a parallel program things change. When we use `pseq` it's
> because we don't want two threads to collide when trying to evaluate
> the same expression. Let's look at an example:
>
> x `par` y `seq` x + y
>
> As you noted, the semantics of `seq` doesn't actually guarantee that
> `y` will be evaluated before `x + y`. But this only matters because
> we've used `par` and introduced threads (via an effect!) and therefore
> the possibility of collision. We can avoid this by using `pseq`
> instead.
>
> So, both `seq` and `pseq` both allow the programmer to express
> *operational* concerns, `seq` is used mostly to eliminate/manage space
> leaks, and `pseq` is used to specify order of evaluation. Those
> concerns sometimes overlap, but they are different!
>
> It could be argued (and I would agree) that `seq` is a bad name; a
> better name might have been something like `synch` [1]. That being
> said, unless we add parallelism to the standard (and even then) I am
> not sure it would be wise to change the operational behavior of `seq`.
> It's current behavior is well established, and if you're writing
> sequential Haskell code where order of evaluation matters, it's
> probably better to reach for a different tool (IMO). However, if
> parallelism is introduced then I'd fight for `pseq` to be part of that
> (as you suggest).
>
> I hope that sheds some light on the issue.
>
> Cheers,
>
> Jose
>
> [1]: John Hughes introduced a `synch` combinator in his thesis, but it
> had very different semantics, so maybe that's a reason it was avoided?
> Someone with more knowledge of the history can probably shed more
> light on this.
>
>
> On Thu, Apr 28, 2016 at 6:56 PM, Takenobu Tani <takenobu.hs at gmail.com
> <javascript:;>> wrote:
> > Dear Community,
> >
> > Apologies if I'm missing context.
> >
> > Does Haskell 2020 specify evaluation order control by `pseq`?
> >
> > We use `pseq` to guarantee the evaluation order between two expressions.
> > But Haskell 2010 did not specify how to control the evaluation order
> between
> > two expressions.
> > (only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't
> > guarantee the order. [2])
> >
> > I think it's better to explicitly specify `pseq` as standard way.
> >
> > Already discussed? or out of scope?
> >
> > [1]:
> >
> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1260006.2
> > [2]:
> >
> https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens
> >
> > Regards,
> > Takenobu
> >
> >
> > _______________________________________________
> > Haskell-prime mailing list
> > Haskell-prime at haskell.org <javascript:;>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> >
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org <javascript:;>
> 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/20160430/b60da517/attachment.html>

From Henrik.Nilsson at nottingham.ac.uk  Sat Apr 30 11:12:26 2016
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Sat, 30 Apr 2016 12:12:26 +0100
Subject: Chairship / responsibility
In-Reply-To: <CALjd_v5aUM08qJNjHjA568cjuNxshmvNeKWRTZQOo4+eYmBs8g@mail.gmail.com>
References: <83F0C468-66F5-4B3F-9337-D3A3B4D229DC@cis.upenn.edu>
 <8760uzmsk4.fsf@gmail.com>
 <CALjd_v5aUM08qJNjHjA568cjuNxshmvNeKWRTZQOo4+eYmBs8g@mail.gmail.com>
Message-ID: <5724931A.6050505@nottingham.ac.uk>

Hi all,

 > It was my understanding that Herbert would be the chair when I asked
 > to be on the committee, and the fact that this question was already
 > answer was a factor in my decision to try to help.

I agree completely with this.

And thanks to Herbert for now having completed the first step of the reboot.

Best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




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 send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From carter.schonwald at gmail.com  Sat Apr 30 12:39:48 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 30 Apr 2016 08:39:48 -0400
Subject: Chairship / responsibility
In-Reply-To: <5724931A.6050505@nottingham.ac.uk>
References: <83F0C468-66F5-4B3F-9337-D3A3B4D229DC@cis.upenn.edu>
 <8760uzmsk4.fsf@gmail.com>
 <CALjd_v5aUM08qJNjHjA568cjuNxshmvNeKWRTZQOo4+eYmBs8g@mail.gmail.com>
 <5724931A.6050505@nottingham.ac.uk>
Message-ID: <CAHYVw0zyHjjBeteaCPOGaA9K5nyyDrerXvW5X7MgSMJwTbrr8w@mail.gmail.com>

On Saturday, April 30, 2016, Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk>
wrote:

> Hi all,
>
> > It was my understanding that Herbert would be the chair when I asked
> > to be on the committee, and the fact that this question was already
> > answer was a factor in my decision to try to help.
>
> I agree completely with this.
>
>
I as well, Herbert chairing was a big part of why I thought participating
would be a productive and worthwhile experience that would accomplish its
stated goals.



> And thanks to Herbert for now having completed the first step of the
> reboot.
>
> Best,
>
> /Henrik
>
> --
> Henrik Nilsson
> School of Computer Science
> The University of Nottingham
> nhn at cs.nott.ac.uk
>
>
>
>
> 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 send it back to me, and immediately delete it.
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
> _______________________________________________
> 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/20160430/7633c84d/attachment.html>

From takenobu.hs at gmail.com  Sat Apr 30 14:16:14 2016
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Sat, 30 Apr 2016 23:16:14 +0900
Subject: Evaluation order control between two expressions
In-Reply-To: <CAPB_NvxDv5bsDTyDRHDk-L5RcpCD9y+_3kd2k_YHcp-1WexBtQ@mail.gmail.com>
References: <CAPB_NvzOXSP4JjF+Jzmd0PSnq+JqH1o25pK=JNYMjie4ABzqmg@mail.gmail.com>
 <CAK+ijdvsH2O6jtv2E_j1QtvXeqfgaQ=rLScZc0iv_0jtW1khnw@mail.gmail.com>
 <CAF3RzK8mqRBPzstnS_G_kCZcH9up6hbu7wZBR9B9--TRHBhLJA@mail.gmail.com>
 <CAPB_NvxDv5bsDTyDRHDk-L5RcpCD9y+_3kd2k_YHcp-1WexBtQ@mail.gmail.com>
Message-ID: <CAPB_NvwUdHutxHiBBQXpUQHR3HBzt9gngt6JBPw6_xXrarvpLQ@mail.gmail.com>

Hi Prime,

This is additional information to organize my brain.

This issue also occurs in single thread.
Especially, when they have side effects.

   seq exp1 exp2

Because compiler can always re-order two expressions
in accordance with seq's denotational semantics.

Regards,
Takenobu


2016-04-30 16:11 GMT+09:00 Takenobu Tani <takenobu.hs at gmail.com>:

> Hi Jose and Cale,
>
> Thank you for clear and detailed explanation.
>
> short summary:
>
>  * `seq`  used to eliminate/manage space leaks
>  * `pseq` used to specify order of evaluation
>
>  * `seq` is a bad name, but well established.
>  * If we introduce parallelism to standard, we need `pseq` or some method.
>
>
> It's depending on whether or not corresponding to the parallelism.
> I learned a lot. Thank you very much.
>
> Regards,
> Takenobu
>
> 2016-04-30 8:17 GMT+09:00 Cale Gibbard <cgibbard at gmail.com>:
>
>> Well, the value of par x y is identical to that of y, so any expression
>> which you could use to semantically distinguish pseq from seq using par
>> could be rewritten into one which did so without involving par.
>>
>> If the way in which we're telling programs apart involves performance
>> characteristics then it may already be possible to distinguish seq from
>> pseq. It somewhat comes down to whether the implementation of the language
>> is clever enough to notice when compiling seq x y any cases where it might
>> be better to finish evaluating y first and simply evaluate x before making
>> the result of that first evaluation available. GHC does do this
>> rearranging, so probably someone can come up with a good example there.
>> On Apr 29, 2016 5:38 PM, "Jos? Manuel Calder?n Trilla" <jmct at jmct.cc>
>> wrote:
>>
>>> Hello Takenobu,
>>>
>>> Great question, this is actually a pretty interesting issue! It isn't
>>> out of scope at all.
>>>
>>> The first thing to think about is the following thought experiment:
>>>
>>> Without the presence of side-effects, how can you tell the difference
>>> between a `seq` that conforms to the Haskell report and one that
>>> evaluates it's first argument before its second?
>>>
>>> If your answer involves `unsafePerformIO` then you're cheating ;)
>>>
>>> Even if your first argument to `seq` is an IO action it won't get
>>> executed because `seq` only evaluates to WHNF. It might be possible to
>>> construct a program that allows you to observe the difference, but in
>>> the general case I don't see how you could. I'd be very interested to
>>> be shown otherwise though!
>>>
>>> Now in a parallel program things change. When we use `pseq` it's
>>> because we don't want two threads to collide when trying to evaluate
>>> the same expression. Let's look at an example:
>>>
>>> x `par` y `seq` x + y
>>>
>>> As you noted, the semantics of `seq` doesn't actually guarantee that
>>> `y` will be evaluated before `x + y`. But this only matters because
>>> we've used `par` and introduced threads (via an effect!) and therefore
>>> the possibility of collision. We can avoid this by using `pseq`
>>> instead.
>>>
>>> So, both `seq` and `pseq` both allow the programmer to express
>>> *operational* concerns, `seq` is used mostly to eliminate/manage space
>>> leaks, and `pseq` is used to specify order of evaluation. Those
>>> concerns sometimes overlap, but they are different!
>>>
>>> It could be argued (and I would agree) that `seq` is a bad name; a
>>> better name might have been something like `synch` [1]. That being
>>> said, unless we add parallelism to the standard (and even then) I am
>>> not sure it would be wise to change the operational behavior of `seq`.
>>> It's current behavior is well established, and if you're writing
>>> sequential Haskell code where order of evaluation matters, it's
>>> probably better to reach for a different tool (IMO). However, if
>>> parallelism is introduced then I'd fight for `pseq` to be part of that
>>> (as you suggest).
>>>
>>> I hope that sheds some light on the issue.
>>>
>>> Cheers,
>>>
>>> Jose
>>>
>>> [1]: John Hughes introduced a `synch` combinator in his thesis, but it
>>> had very different semantics, so maybe that's a reason it was avoided?
>>> Someone with more knowledge of the history can probably shed more
>>> light on this.
>>>
>>>
>>> On Thu, Apr 28, 2016 at 6:56 PM, Takenobu Tani <takenobu.hs at gmail.com>
>>> wrote:
>>> > Dear Community,
>>> >
>>> > Apologies if I'm missing context.
>>> >
>>> > Does Haskell 2020 specify evaluation order control by `pseq`?
>>> >
>>> > We use `pseq` to guarantee the evaluation order between two
>>> expressions.
>>> > But Haskell 2010 did not specify how to control the evaluation order
>>> between
>>> > two expressions.
>>> > (only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't
>>> > guarantee the order. [2])
>>> >
>>> > I think it's better to explicitly specify `pseq` as standard way.
>>> >
>>> > Already discussed? or out of scope?
>>> >
>>> > [1]:
>>> >
>>> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1260006.2
>>> > [2]:
>>> >
>>> https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens
>>> >
>>> > Regards,
>>> > Takenobu
>>> >
>>> >
>>> > _______________________________________________
>>> > Haskell-prime mailing list
>>> > Haskell-prime at haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>> >
>>> _______________________________________________
>>> 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/20160430/e2d116a7/attachment.html>

From carter.schonwald at gmail.com  Sat Apr 30 14:20:46 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 30 Apr 2016 14:20:46 +0000
Subject: Evaluation order control between two expressions
In-Reply-To: <CAPB_NvwUdHutxHiBBQXpUQHR3HBzt9gngt6JBPw6_xXrarvpLQ@mail.gmail.com>
References: <CAPB_NvzOXSP4JjF+Jzmd0PSnq+JqH1o25pK=JNYMjie4ABzqmg@mail.gmail.com>
 <CAK+ijdvsH2O6jtv2E_j1QtvXeqfgaQ=rLScZc0iv_0jtW1khnw@mail.gmail.com>
 <CAF3RzK8mqRBPzstnS_G_kCZcH9up6hbu7wZBR9B9--TRHBhLJA@mail.gmail.com>
 <CAPB_NvxDv5bsDTyDRHDk-L5RcpCD9y+_3kd2k_YHcp-1WexBtQ@mail.gmail.com>
 <CAPB_NvwUdHutxHiBBQXpUQHR3HBzt9gngt6JBPw6_xXrarvpLQ@mail.gmail.com>
Message-ID: <CAHYVw0zMAc3dz=A+2fPj9G0twch=Fdhb9orP+=5zf789fBnOLA@mail.gmail.com>

On Sat, Apr 30, 2016, 10:16 AM Takenobu Tani <takenobu.hs at gmail.com> wrote:

> Hi Prime,
>
> This is additional information to organize my brain.
>
> This issue also occurs in single thread.
> Especially, when they have side effects.
>
>    seq exp1 exp2
>
> Because compiler can always re-order two expressions
> in accordance with seq's denotational semantics.
>
> Regards,
> Takenobu
>

That requires / presumes a none idempotent use of unsafe perform io in
those  sub expressions right?



>
> 2016-04-30 16:11 GMT+09:00 Takenobu Tani <takenobu.hs at gmail.com>:
>
>> Hi Jose and Cale,
>>
>> Thank you for clear and detailed explanation.
>>
>> short summary:
>>
>>  * `seq`  used to eliminate/manage space leaks
>>  * `pseq` used to specify order of evaluation
>>
>>  * `seq` is a bad name, but well established.
>>  * If we introduce parallelism to standard, we need `pseq` or some method.
>>
>>
>> It's depending on whether or not corresponding to the parallelism.
>> I learned a lot. Thank you very much.
>>
>> Regards,
>> Takenobu
>>
>> 2016-04-30 8:17 GMT+09:00 Cale Gibbard <cgibbard at gmail.com>:
>>
>>> Well, the value of par x y is identical to that of y, so any expression
>>> which you could use to semantically distinguish pseq from seq using par
>>> could be rewritten into one which did so without involving par.
>>>
>>> If the way in which we're telling programs apart involves performance
>>> characteristics then it may already be possible to distinguish seq from
>>> pseq. It somewhat comes down to whether the implementation of the language
>>> is clever enough to notice when compiling seq x y any cases where it might
>>> be better to finish evaluating y first and simply evaluate x before making
>>> the result of that first evaluation available. GHC does do this
>>> rearranging, so probably someone can come up with a good example there.
>>> On Apr 29, 2016 5:38 PM, "Jos? Manuel Calder?n Trilla" <jmct at jmct.cc>
>>> wrote:
>>>
>>>> Hello Takenobu,
>>>>
>>>> Great question, this is actually a pretty interesting issue! It isn't
>>>> out of scope at all.
>>>>
>>>> The first thing to think about is the following thought experiment:
>>>>
>>>> Without the presence of side-effects, how can you tell the difference
>>>> between a `seq` that conforms to the Haskell report and one that
>>>> evaluates it's first argument before its second?
>>>>
>>>> If your answer involves `unsafePerformIO` then you're cheating ;)
>>>>
>>>> Even if your first argument to `seq` is an IO action it won't get
>>>> executed because `seq` only evaluates to WHNF. It might be possible to
>>>> construct a program that allows you to observe the difference, but in
>>>> the general case I don't see how you could. I'd be very interested to
>>>> be shown otherwise though!
>>>>
>>>> Now in a parallel program things change. When we use `pseq` it's
>>>> because we don't want two threads to collide when trying to evaluate
>>>> the same expression. Let's look at an example:
>>>>
>>>> x `par` y `seq` x + y
>>>>
>>>> As you noted, the semantics of `seq` doesn't actually guarantee that
>>>> `y` will be evaluated before `x + y`. But this only matters because
>>>> we've used `par` and introduced threads (via an effect!) and therefore
>>>> the possibility of collision. We can avoid this by using `pseq`
>>>> instead.
>>>>
>>>> So, both `seq` and `pseq` both allow the programmer to express
>>>> *operational* concerns, `seq` is used mostly to eliminate/manage space
>>>> leaks, and `pseq` is used to specify order of evaluation. Those
>>>> concerns sometimes overlap, but they are different!
>>>>
>>>> It could be argued (and I would agree) that `seq` is a bad name; a
>>>> better name might have been something like `synch` [1]. That being
>>>> said, unless we add parallelism to the standard (and even then) I am
>>>> not sure it would be wise to change the operational behavior of `seq`.
>>>> It's current behavior is well established, and if you're writing
>>>> sequential Haskell code where order of evaluation matters, it's
>>>> probably better to reach for a different tool (IMO). However, if
>>>> parallelism is introduced then I'd fight for `pseq` to be part of that
>>>> (as you suggest).
>>>>
>>>> I hope that sheds some light on the issue.
>>>>
>>>> Cheers,
>>>>
>>>> Jose
>>>>
>>>> [1]: John Hughes introduced a `synch` combinator in his thesis, but it
>>>> had very different semantics, so maybe that's a reason it was avoided?
>>>> Someone with more knowledge of the history can probably shed more
>>>> light on this.
>>>>
>>>>
>>>> On Thu, Apr 28, 2016 at 6:56 PM, Takenobu Tani <takenobu.hs at gmail.com>
>>>> wrote:
>>>> > Dear Community,
>>>> >
>>>> > Apologies if I'm missing context.
>>>> >
>>>> > Does Haskell 2020 specify evaluation order control by `pseq`?
>>>> >
>>>> > We use `pseq` to guarantee the evaluation order between two
>>>> expressions.
>>>> > But Haskell 2010 did not specify how to control the evaluation order
>>>> between
>>>> > two expressions.
>>>> > (only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't
>>>> > guarantee the order. [2])
>>>> >
>>>> > I think it's better to explicitly specify `pseq` as standard way.
>>>> >
>>>> > Already discussed? or out of scope?
>>>> >
>>>> > [1]:
>>>> >
>>>> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1260006.2
>>>> > [2]:
>>>> >
>>>> https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens
>>>> >
>>>> > Regards,
>>>> > Takenobu
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Haskell-prime mailing list
>>>> > Haskell-prime at haskell.org
>>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>>> >
>>>> _______________________________________________
>>>> Haskell-prime mailing list
>>>> Haskell-prime at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>>>
>>>
>>
> _______________________________________________
> 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/20160430/62db770e/attachment-0001.html>

From johnw at newartisans.com  Sat Apr 30 20:03:48 2016
From: johnw at newartisans.com (John Wiegley)
Date: Sat, 30 Apr 2016 13:03:48 -0700
Subject: Chairship / responsibility
In-Reply-To: <5724931A.6050505@nottingham.ac.uk> (Henrik Nilsson's message of
 "Sat, 30 Apr 2016 12:12:26 +0100")
References: <83F0C468-66F5-4B3F-9337-D3A3B4D229DC@cis.upenn.edu>
 <8760uzmsk4.fsf@gmail.com>
 <CALjd_v5aUM08qJNjHjA568cjuNxshmvNeKWRTZQOo4+eYmBs8g@mail.gmail.com>
 <5724931A.6050505@nottingham.ac.uk>
Message-ID: <m21t5mj23f.fsf@newartisans.com>

>>>>> Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk> writes:

>> It was my understanding that Herbert would be the chair when I asked to be
>> on the committee, and the fact that this question was already answer was a
>> factor in my decision to try to help.

> I agree completely with this.

I also agree, and offer my thanks to Herbert for being willing to take up this
role from the beginning.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

From jmct at jmct.cc  Sat Apr 30 20:09:15 2016
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Sat, 30 Apr 2016 16:09:15 -0400
Subject: Chairship / responsibility
In-Reply-To: <m21t5mj23f.fsf@newartisans.com>
References: <83F0C468-66F5-4B3F-9337-D3A3B4D229DC@cis.upenn.edu>
 <8760uzmsk4.fsf@gmail.com>
 <CALjd_v5aUM08qJNjHjA568cjuNxshmvNeKWRTZQOo4+eYmBs8g@mail.gmail.com>
 <5724931A.6050505@nottingham.ac.uk>
 <m21t5mj23f.fsf@newartisans.com>
Message-ID: <CAK+ijdv619xvcYX0+3WaRY7_09ub4L3ajDNiA61AnHzdwCxGAQ@mail.gmail.com>

On Sat, Apr 30, 2016 at 4:03 PM, John Wiegley <johnw at newartisans.com> wrote:
>>>>>> Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk> writes:
>
>>> It was my understanding that Herbert would be the chair when I asked to be
>>> on the committee, and the fact that this question was already answer was a
>>> factor in my decision to try to help.
>
>> I agree completely with this.
>
> I also agree, and offer my thanks to Herbert for being willing to take up this
> role from the beginning.

Same here.

From jmct at jmct.cc  Sat Apr 30 20:28:46 2016
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Sat, 30 Apr 2016 16:28:46 -0400
Subject: Evaluation order control between two expressions
In-Reply-To: <CAJogeqfGGe4Cg3brfWsY1uJzVV6Kv+UR30xjmmgqQCm8_RP+-w@mail.gmail.com>
References: <CAPB_NvzOXSP4JjF+Jzmd0PSnq+JqH1o25pK=JNYMjie4ABzqmg@mail.gmail.com>
 <CAK+ijdvsH2O6jtv2E_j1QtvXeqfgaQ=rLScZc0iv_0jtW1khnw@mail.gmail.com>
 <CAJogeqfGGe4Cg3brfWsY1uJzVV6Kv+UR30xjmmgqQCm8_RP+-w@mail.gmail.com>
Message-ID: <CAK+ijdtZtawyuBTLbf8DnoSMAFuhK2jyM5m-BE8s4-RmPLrLaQ@mail.gmail.com>

On Sat, Apr 30, 2016 at 6:11 AM, Lennart Augustsson
<lennart at augustsson.net> wrote:
> Order of evaluation can be very important for memory use.  So I can imagine
> cases where seq would run out of memory, but pseq would not.
>

That's fair enough. Do you think it's worth attempting to standardize
the behavior of `seq` to be like `pseq`?

> I would argue that pseq is almost always what you want, but seq has a nicer
> denotational semantics.

Is this the reason it wasn't standardized this way to begin with?
Miranda's `seq` is like `pseq` (as was `seq` in other lazy language
implementations) so it's not as if there wasn't precedent.

From johnw at newartisans.com  Sat Apr 30 21:15:41 2016
From: johnw at newartisans.com (John Wiegley)
Date: Sat, 30 Apr 2016 14:15:41 -0700
Subject: Evaluation order control between two expressions
In-Reply-To: <CAK+ijdtZtawyuBTLbf8DnoSMAFuhK2jyM5m-BE8s4-RmPLrLaQ@mail.gmail.com>
 (=?utf-8?Q?=22Jos=C3=A9?= Manuel =?utf-8?Q?Calder=C3=B3n?= Trilla"'s
 message of "Sat, 30 Apr 2016 16:28:46 -0400")
References: <CAPB_NvzOXSP4JjF+Jzmd0PSnq+JqH1o25pK=JNYMjie4ABzqmg@mail.gmail.com>
 <CAK+ijdvsH2O6jtv2E_j1QtvXeqfgaQ=rLScZc0iv_0jtW1khnw@mail.gmail.com>
 <CAJogeqfGGe4Cg3brfWsY1uJzVV6Kv+UR30xjmmgqQCm8_RP+-w@mail.gmail.com>
 <CAK+ijdtZtawyuBTLbf8DnoSMAFuhK2jyM5m-BE8s4-RmPLrLaQ@mail.gmail.com>
Message-ID: <m28tzuhk76.fsf@newartisans.com>

>>>>> Jos? Manuel Calder?n Trilla <jmct at jmct.cc> writes:

> Is this the reason it wasn't standardized this way to begin with? Miranda's
> `seq` is like `pseq` (as was `seq` in other lazy language implementations)
> so it's not as if there wasn't precedent.

Note that this has been discussed previously, but another incarnation of the
Prime committee:

https://mail.haskell.org/pipermail/glasgow-haskell-users/2006-November/011480.html

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

From austin at well-typed.com  Sat Apr 30 22:22:44 2016
From: austin at well-typed.com (Austin Seipp)
Date: Sat, 30 Apr 2016 17:22:44 -0500
Subject: Infrastructure & Communication
In-Reply-To: <etPan.5724354e.3a964cf9.14c@mbp.local>
References: <87pot9ieho.fsf@gmail.com> <20160429111540.GA22682@casa.casa>
 <57235EE1.80203@ciktel.net>
 <CABUjdS6ciar24nUVx=rvqwFQgmEZYuOpps8Tua_O_TQmMJWBuQ@mail.gmail.com>
 <etPan.5724354e.3a964cf9.14c@mbp.local>
Message-ID: <CAEs96n182H+j3Kzf4+E5m+w9V9oq0aywn564PeNbNxK_5d2wrQ@mail.gmail.com>

Some random meta thoughts:

I'm generally OK with using some newer, external service over Trac for
our work. My impression is that everyone on board is probably OK with
starting fresh for this iteration of the committee, and
recycling/cleaning up any proposals or data we deem important anyway.
The 'technical debt' here is very minimal. So whatever we choose, I
think as long as we're happy, it will be OK.

I understand the complaint about SaaS/proprietary services, and do
think it's important. But I'm not going to cast an enormous vote of
strong disapproval or anything if I lose that, or anything. (Getting
work done on Prime itself is a more important battle to fight,
honestly).

Phabricator might have some OK advantages. It's a bit unfamiliar, but
does have some technical bonuses, and isn't likely to go away soon
thanks to its infrastructure/GHC use:

  - We can have something like an indexable, persistent IRC room we
can all use. I do generally prefer immediate methods of discussion,
but asynchronous messaging and persistent logs (even when offline) are
an important value add, and IRC fails here IMO.
  - It has strong access control mechanisms. This means the Prime
committee can do things like have private discussion, outside of usual
e.g. email. I know people are intimately leery of this, but I think in
practice people form private discussion channels anyway, and having
private avenues for discussing larger public things in an easy way
(chat rooms, tickets etc) is desirable. The lack of a sanctioned
private channel IMO will only cause Prime members to discuss in
private *anyway*, but in disjoint groups probably. I don't think we
should use it all the time, but I can imagine we might want this - I
didn't see it brought up.
  - It has some other useful facilities aside from bug-tracking
obviously, like voting tools, which could come in handy for some
things. I personally hate using mailing lists for outright voting
processes. (For example, see a vote a while back about GHC buildbots:
https://phabricator.haskell.org/V3)

Note: None of these (except point #2) is important to inspire 'clear
superiority', IMO. It's mostly just technical icing on top of the
rudimentary things we need. I think #2 is important, but we can use
other private means of course.

(I'd prefer not to get derailed at all on the meager technical bits
above - although I would like to know in general what people think
about #2)

I do think GitHub would be nice for it's workflow features, however.
Phabricator doesn't allow patches with 'git push' yet (it will soon)
and I know people get anxious about arcanist. Obviously we value
outside input, so 3rd party reach and low friction is an important
factor to keep motivation, which Phabricator is behind on. (It's
engineered as a long-term productivity tool by the devs - so immediate
familiarity is seen as a low cost on the long scale for the vast array
of users.) Even then, just the difference in the tool may be enough to
deter some people.

On that note, I generally think that with a good edit workflow, we
shouldn't really need wiki processes at all. I'm with Wren, here -
wikis are nice for a draft, but in practice it's very. very nice to
have drafts publicly version controlled, in the same way code is. In
light of that, an issue tracker for discussion, + a formative patch is
enough, I think.

I'm reading into the specifics of the Rust/Go/etc RFC process. Python
also has a similar one I believe, although PEPs predate these other
languages quite a lot, and probably served as their own inspiration,
too. So, another useful data point to think about.

On Fri, Apr 29, 2016 at 11:31 PM, Gershom B <gershomb at gmail.com> wrote:
> On April 29, 2016 at 10:49:38 PM, wren romano (wren at community.haskell.org) wrote:
>>
>> I like (something like) GitHub issues for tracking the exact content
>> of proposed changes and their (direct) commentary. As far as the
>> particular tool I'm mostly agnostic, but lean slightly towards github
>> over trac. I've never used phabricator so can't say there (though I'm
>> slightly against, as it'd be another tool to learn.)
>>
>
> If github makes sense but there is a concern over a permanent record that is not in the custody solely of a private company, then there is a nice tool (in haskell no less) that will pull the various associated data of a repo (including issues) into a branch in the repo itself [1].
>
> We could then script a regular pull of the repo into some common haskell community infrastructure.
>
> Cheers,
> Gershom
>
> [1] https://github.com/joeyh/github-backup
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Sat Apr 30 22:28:16 2016
From: austin at well-typed.com (Austin Seipp)
Date: Sat, 30 Apr 2016 17:28:16 -0500
Subject: Chairship / responsibility
In-Reply-To: <CAK+ijdv619xvcYX0+3WaRY7_09ub4L3ajDNiA61AnHzdwCxGAQ@mail.gmail.com>
References: <83F0C468-66F5-4B3F-9337-D3A3B4D229DC@cis.upenn.edu>
 <8760uzmsk4.fsf@gmail.com>
 <CALjd_v5aUM08qJNjHjA568cjuNxshmvNeKWRTZQOo4+eYmBs8g@mail.gmail.com>
 <5724931A.6050505@nottingham.ac.uk>
 <m21t5mj23f.fsf@newartisans.com>
 <CAK+ijdv619xvcYX0+3WaRY7_09ub4L3ajDNiA61AnHzdwCxGAQ@mail.gmail.com>
Message-ID: <CAEs96n1HStw=be_AD=to3Ee4sMD_mUXruWA_9HKecZxNrRF_cw@mail.gmail.com>

Yes, I'm essentially on-board thanks to Herbert, who I know tends to
get shit done, and do it well.

Sorry Herbert - I think you're going to be unanimously voted in this
time, whatever exact details we sort out (like rotating committee
chairs). Perhaps we should let you think about those details and
advise us on them. :)

On Sat, Apr 30, 2016 at 3:09 PM, Jos? Manuel Calder?n Trilla
<jmct at jmct.cc> wrote:
> On Sat, Apr 30, 2016 at 4:03 PM, John Wiegley <johnw at newartisans.com> wrote:
>>>>>>> Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk> writes:
>>
>>>> It was my understanding that Herbert would be the chair when I asked to be
>>>> on the committee, and the fact that this question was already answer was a
>>>> factor in my decision to try to help.
>>
>>> I agree completely with this.
>>
>> I also agree, and offer my thanks to Herbert for being willing to take up this
>> role from the beginning.
>
> Same here.
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/