From takenobu.hs at gmail.com  Sun May  1 00:47:38 2016
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Sun, 1 May 2016 09:47:38 +0900
Subject: Evaluation order control between two expressions
In-Reply-To: <CAHYVw0zMAc3dz=A+2fPj9G0twch=Fdhb9orP+=5zf789fBnOLA@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>
 <CAHYVw0zMAc3dz=A+2fPj9G0twch=Fdhb9orP+=5zf789fBnOLA@mail.gmail.com>
Message-ID: <CAPB_Nvwy9yXUu6qLEj8tJrmPCfRWOEadN3x8k0pKqCJuLs0Qug@mail.gmail.com>

Hi Carter,

You are right. I had mixed case.
In single thread case, I implicitly assumed IO context rather than pure
parallel context.

Thank you for explanation.

Regards,
Takenobu


2016-04-30 23:20 GMT+09:00 Carter Schonwald <carter.schonwald at 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/20160501/20aa0ac8/attachment-0001.html>

From eir at cis.upenn.edu  Sun May  1 00:59:50 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 30 Apr 2016 20:59:50 -0400
Subject: Chairship / responsibility
In-Reply-To: <CAEs96n1HStw=be_AD=to3Ee4sMD_mUXruWA_9HKecZxNrRF_cw@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>
 <CAEs96n1HStw=be_AD=to3Ee4sMD_mUXruWA_9HKecZxNrRF_cw@mail.gmail.com>
Message-ID: <93A29FEF-4853-473F-B94D-3DA2F7DBE61E@cis.upenn.edu>

Excellent. I'm very happy with how this thread has gone. :)

(I didn't mean to imply, by the way, that we were slow to answer the `pseq` question. It's just that as I was about to move the email out of my inbox, I realized that we might all do so, and that would be bad. Yes, a few days' time is quite reasonable before anyone has to step in.)

Richard

On Apr 30, 2016, at 6:28 PM, Austin Seipp <austin at well-typed.com> wrote:

> 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/
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> 


From carter.schonwald at gmail.com  Sun May  1 02:42:42 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 01 May 2016 02:42:42 +0000
Subject: Evaluation order control between two expressions
In-Reply-To: <CAPB_Nvwy9yXUu6qLEj8tJrmPCfRWOEadN3x8k0pKqCJuLs0Qug@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>
 <CAHYVw0zMAc3dz=A+2fPj9G0twch=Fdhb9orP+=5zf789fBnOLA@mail.gmail.com>
 <CAPB_Nvwy9yXUu6qLEj8tJrmPCfRWOEadN3x8k0pKqCJuLs0Qug@mail.gmail.com>
Message-ID: <CAHYVw0xj3+GOC3yJziZRySW1WLZB_6v+CofBDP95mVa9u=WMcw@mail.gmail.com>

On Sat, Apr 30, 2016 at 8:47 PM Takenobu Tani <takenobu.hs at gmail.com> wrote:

> Hi Carter,
>
> You are right. I had mixed case.
> In single thread case, I implicitly assumed IO context rather than pure
> parallel context.
>
>
thank you for your wonderful questions!


> Thank you for explanation.
>
> Regards,
> Takenobu
>
>
> 2016-04-30 23:20 GMT+09:00 Carter Schonwald <carter.schonwald at 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/20160501/27f3d2ed/attachment.html>

From nicolas.wu at gmail.com  Sun May  1 05:53:52 2016
From: nicolas.wu at gmail.com (Nicolas Wu)
Date: Sun, 1 May 2016 06:53:52 +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: <CAFBp9R=xC7v1zxb689Y-W3BHdLUXicP8xjrtdAKaRRRnfUmWSw@mail.gmail.com>

Having Herbert as chair was also my understanding, and I'm very happy
for him to chair these discussions.

Nick

On 30 April 2016 at 09:38, Andres L?h <andres.loeh at googlemail.com> wrote:
> 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
>>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

From johnw at newartisans.com  Mon May  2 22:57:38 2016
From: johnw at newartisans.com (John Wiegley)
Date: Mon, 02 May 2016 15:57:38 -0700
Subject: Are there GHC extensions we'd like to incorporate wholesale?
Message-ID: <m2bn4orrtp.fsf@newartisans.com>

I wonder if there are GHC extensions we'd like to promote as features in the
next report, as a starting point for discussing new additions.

There are a few GHC features that have become part of the regular Haskell
landscape, such that it's hard to imagine a modern Haskell without them. For
example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.

How much "work" is typically involved in promoting a feature to be in the
Report, and how do we determine when it's a bad idea?

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

From crmills_2000 at yahoo.com  Tue May  3 00:55:09 2016
From: crmills_2000 at yahoo.com (Carlton Mills)
Date: Tue, 3 May 2016 00:55:09 +0000 (UTC)
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <m2bn4orrtp.fsf@newartisans.com>
References: <m2bn4orrtp.fsf@newartisans.com>
Message-ID: <1452701024.6486935.1462236909257.JavaMail.yahoo@mail.yahoo.com>

One objective would be to compile the Haskel Platform with near zero extensions. 

    On Monday, May 2, 2016 5:57 PM, John Wiegley <johnw at newartisans.com> wrote:
 

 I wonder if there are GHC extensions we'd like to promote as features in the
next report, as a starting point for discussing new additions.

There are a few GHC features that have become part of the regular Haskell
landscape, such that it's hard to imagine a modern Haskell without them. For
example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.

How much "work" is typically involved in promoting a feature to be in the
Report, and how do we determine when it's a bad idea?

-- 
John Wiegley? ? ? ? ? ? ? ? ? GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com ? ? ? ? ? ? ? ? ? ? ? ? 60E1 46C4 BD1A 7AC1 4BA2
_______________________________________________
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/20160503/cdcb67c2/attachment.html>

From eir at cis.upenn.edu  Tue May  3 01:33:21 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 2 May 2016 21:33:21 -0400
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <m2bn4orrtp.fsf@newartisans.com>
References: <m2bn4orrtp.fsf@newartisans.com>
Message-ID: <B45D1D2F-7D87-4D5B-930B-C9F3A5E7A2E1@cis.upenn.edu>

Great questions. Here's my take:

For something to be incorporated into the standard, we'd need to be able to give a concrete, precise description of how the extension changes the set of correct Haskell programs. We also need to consider how the extension changes properties of the language, like predictability of performance or class coherence.

For the four you mention, here are my thoughts:

MultiParamTypeClasses: Can't these be used to create incoherence? I seem to recall hearing this once. I'm in general in favor of including these, but would want to reflect on the coherence question a bit.

OverloadedStrings: This seems very straightforward. But it's quite easy to conceive of times when I wouldn't want this feature in the language. If the extension becomes part of the standard, is there a way to turn it off? If not, Haskell2020 would not be a conservative extension of Haskell2010.

GADTs: While GADTSyntax seems straightforward, GADT type inference is far from. Do we have a description of GADT type inference that doesn't rely on thinking about variable unification? Even if we're OK putting unification into the standard, GHC's current inference capabilities are still not very finely mapped. (Note that the inference algorithm in the OutsideIn paper is incomplete with respect to the specification in that paper.)

TypeFamilies: I think there's quite a bit more to understand about type families before they could be standardized. First off, they come in many flavors (associated, open, closed). Do we want to include all of the flavors? How do partial type families really operate? I wrote a blog post [1] exploring this topic and had more questions than answers. What about termination checking? Or do we want to allow non-terminating definitions and discard decidability of type inference?

Of course, I recognize that John picked just a few arbitrary popular extensions. But even these extensions have a lot of dark corners, and my answers above are just to highlight that there's real work to be done, even with very popular extensions.

Richard

[1]: https://typesandkinds.wordpress.com/2015/09/09/what-are-type-families/

On May 2, 2016, at 6:57 PM, "John Wiegley" <johnw at newartisans.com> wrote:

> I wonder if there are GHC extensions we'd like to promote as features in the
> next report, as a starting point for discussing new additions.
> 
> There are a few GHC features that have become part of the regular Haskell
> landscape, such that it's hard to imagine a modern Haskell without them. For
> example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.
> 
> How much "work" is typically involved in promoting a feature to be in the
> Report, and how do we determine when it's a bad idea?
> 
> -- 
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


From mgsloan at gmail.com  Tue May  3 02:41:40 2016
From: mgsloan at gmail.com (Michael Sloan)
Date: Mon, 2 May 2016 19:41:40 -0700
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <m2bn4orrtp.fsf@newartisans.com>
References: <m2bn4orrtp.fsf@newartisans.com>
Message-ID: <CAEDDsWcbP0LHLUXfKuHkh_0gw6pPH+skhPqacx_ET5L6aniKzA@mail.gmail.com>

In this issue on the hpack tracker, I describe my swing at coming up with a
conservative set of extensions:

https://github.com/sol/hpack/issues/94

The list I ended up with is:

LambdaCase, GADTSyntax, ScopedTypeVariables, TupleSections, BangPatterns,
FlexibleInstances, FlexibleContexts, MultiWayIf, TypeOperators,
FunctionalDependencies,
BinaryLiterals, RecursiveDo, ParallelListComp, PartialTypeSignatures,
EmptyCase, InstanceSigs

Not sure about FlexibleInstances, EmptyCase, or TupleSections (see the
issue).

If some set like this is accepted, then that "just" leaves figuring out the
set of more complicated type system extensions :)

-Michael

On Mon, May 2, 2016 at 3:57 PM, John Wiegley <johnw at newartisans.com> wrote:

> I wonder if there are GHC extensions we'd like to promote as features in
> the
> next report, as a starting point for discussing new additions.
>
> There are a few GHC features that have become part of the regular Haskell
> landscape, such that it's hard to imagine a modern Haskell without them.
> For
> example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies,
> etc.
>
> How much "work" is typically involved in promoting a feature to be in the
> Report, and how do we determine when it's a bad idea?
>
> --
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
> _______________________________________________
> 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/20160502/e5f1287c/attachment.html>

From mgsloan at gmail.com  Tue May  3 02:47:24 2016
From: mgsloan at gmail.com (Michael Sloan)
Date: Mon, 2 May 2016 19:47:24 -0700
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <CAEDDsWcbP0LHLUXfKuHkh_0gw6pPH+skhPqacx_ET5L6aniKzA@mail.gmail.com>
References: <m2bn4orrtp.fsf@newartisans.com>
 <CAEDDsWcbP0LHLUXfKuHkh_0gw6pPH+skhPqacx_ET5L6aniKzA@mail.gmail.com>
Message-ID: <CAEDDsWem1sUG=mnJrHM=p1fnBAZgqHYubbteDSWHiix1obsh2w@mail.gmail.com>

Doh, left off MultiParamTypeClasses from the list in the email.  Though, as
Richard mentions, apparently this should be carefully considered with
regards to coherence.

On Mon, May 2, 2016 at 7:41 PM, Michael Sloan <mgsloan at gmail.com> wrote:

> In this issue on the hpack tracker, I describe my swing at coming up with
> a conservative set of extensions:
>
> https://github.com/sol/hpack/issues/94
>
> The list I ended up with is:
>
> LambdaCase, GADTSyntax, ScopedTypeVariables, TupleSections, BangPatterns,
> FlexibleInstances, FlexibleContexts, MultiWayIf, TypeOperators,
> FunctionalDependencies,
> BinaryLiterals, RecursiveDo, ParallelListComp, PartialTypeSignatures,
> EmptyCase, InstanceSigs
>
> Not sure about FlexibleInstances, EmptyCase, or TupleSections (see the
> issue).
>
> If some set like this is accepted, then that "just" leaves figuring out
> the set of more complicated type system extensions :)
>
> -Michael
>
> On Mon, May 2, 2016 at 3:57 PM, John Wiegley <johnw at newartisans.com>
> wrote:
>
>> I wonder if there are GHC extensions we'd like to promote as features in
>> the
>> next report, as a starting point for discussing new additions.
>>
>> There are a few GHC features that have become part of the regular Haskell
>> landscape, such that it's hard to imagine a modern Haskell without them.
>> For
>> example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies,
>> etc.
>>
>> How much "work" is typically involved in promoting a feature to be in the
>> Report, and how do we determine when it's a bad idea?
>>
>> --
>> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
>> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>> _______________________________________________
>> 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/20160502/d9ce4a78/attachment-0001.html>

From austin at well-typed.com  Tue May  3 03:36:28 2016
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 2 May 2016 22:36:28 -0500
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <B45D1D2F-7D87-4D5B-930B-C9F3A5E7A2E1@cis.upenn.edu>
References: <m2bn4orrtp.fsf@newartisans.com>
 <B45D1D2F-7D87-4D5B-930B-C9F3A5E7A2E1@cis.upenn.edu>
Message-ID: <CAEs96n2o-AVHM9CPTnZ82bUerKGS5ZhxXsW5C-oCkwWMpYdD=w@mail.gmail.com>

IMO, the committee should not focus on most these at the moment,
because there are easier wins to be had - most of the open proposed
ones have problems that make the discussion veer from "Very Obvious"
to "Not so obvious". I know they're popular, but doing this is going
to require a lot more discussion.

A few points:

  - MPTCs. I'm OK with this by itself but it's not very useful without
some constituent thing like Fundeps or type families. Richard, when
you say there's an incoherence problem, can you be more specific? The
more recent one I was reminded of was that FlexibleInstances can
violate coherence, but that's a bit more subtle - maybe that's what
you meant? I'm not sure if it's enough to keep it out. See
https://gist.github.com/rwbarton/dd8e51dce2a262d17a80 for an example.

  - OverloadedStrings are less trivial than you think. Because:

$ ghci
GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
Prelude> :set -XOverloadedStrings
Prelude> length "foo"

<interactive>:3:1:
    No instance for (Foldable t0) arising from a use of ?length?
    The type variable ?t0? is ambiguous
    ...

  Yes, I know, the FTP, etc etc etc. However, that makes a lot of
simple code examples break in the case of overloaded functions that
can't pick the right base type. There's obviously still some back and
forth to be done, perhaps the FTP could be refined for Haskell2020.
Anyway, my point is this is less initially trivial than it might seem
to some.

  - GADTs are an extension I like dearly, but I think they are also
not so simple. I think the Haskell report is fairly careful, as it
stands, not to dictate much about inference strategies. GADTs surface
these changes, for example, by ensuring let is not generalized. I
think the committee could come to something on this perhaps, but it is
not so simple. Deviating from this is something we can decide to do,
but not easily.

  - Richard touched on it only as an side, but GADT syntax would be
excellent. I would even like it to be enshrined by the standard as the
default (perhaps modulo ExistentialQuantification). In fact I like it
so much that it gets its own bullet point. That's for another day,
just saying.

  - Type families, I think, are not as well understood and have
changed far too quickly, in recent memory, to talk about this early
on, as Richard said.

I think that at the moment we should focus on making the process easy
so we can keep our motivation up. Taking on large extensions is going
to lead to bikeshedding and drain people, I think, which would be a
real bad thing to happen after so much hubbub. I know many people on
the committee are probably going to have feelings similar to the
above.

If we are going to talk about "wholesale incorporation", there are
many simplier, much more obvious extensions. Plus, these will give us
a chance to go at the process and try to find something that works for
us. Or at least makes us all equally unhappy (the definition of good
compromise). Much easier to test out how we want things to go when the
stakes are much lower.

I like the list Michael Sloan suggested elsewhere, or something like
it. Many many more obvious extensions to be had:

  - RecursiveDo
  - LambdaCase
  - TupleSections (surprisingly popular, in the "would use frequently
if always on"-category, it seems)
  - GADTSyntax (already definitively asserted as great)
  - BinaryLiterals
  - EmptyCase
  - InstanceSigs
  - ParallelListComp

I seem to remember MultiWayIf having some kind of weird interaction
with the lexer to make it abide by the proper block rules, but I'd
probably also vote for it anyway.

I intentionally left off anything that didn't seem somewhat blindingly
obvious, and some that you might think suspiciously absent I know for
a fact someone might pipe up and say "But wait!" -- Anyway, the point
is to get some easy wins. Maybe others are ones we incorporate
wholesale too, but let's just target a couple really clear ones.

The thread about the RFC/editing process is still ongoing, but I think
we could easily add the above ones with only a couple rounds of
intense, heated debate, and that would be a good warm up.

Traditionally, I think proposals were actually sent including what
were basically literal deltas to the Haskell Report, pretty much,
including how it would be described and added. Obviously we want
source control to do that now.

I'd be willing to be a guinea pig and submit a couple of the above
ones for some trial runs on the process, if people think this is an OK
place to start. We'll probably have to nail the exact RFC method down,
though, in the other thread on the list. I also probably wouldn't get
to it until the end of this week, so that's likely for the best
anyway.

On Mon, May 2, 2016 at 8:33 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Great questions. Here's my take:
>
> For something to be incorporated into the standard, we'd need to be able to give a concrete, precise description of how the extension changes the set of correct Haskell programs. We also need to consider how the extension changes properties of the language, like predictability of performance or class coherence.
>
> For the four you mention, here are my thoughts:
>
> MultiParamTypeClasses: Can't these be used to create incoherence? I seem to recall hearing this once. I'm in general in favor of including these, but would want to reflect on the coherence question a bit.
>
> OverloadedStrings: This seems very straightforward. But it's quite easy to conceive of times when I wouldn't want this feature in the language. If the extension becomes part of the standard, is there a way to turn it off? If not, Haskell2020 would not be a conservative extension of Haskell2010.
>
> GADTs: While GADTSyntax seems straightforward, GADT type inference is far from. Do we have a description of GADT type inference that doesn't rely on thinking about variable unification? Even if we're OK putting unification into the standard, GHC's current inference capabilities are still not very finely mapped. (Note that the inference algorithm in the OutsideIn paper is incomplete with respect to the specification in that paper.)
>
> TypeFamilies: I think there's quite a bit more to understand about type families before they could be standardized. First off, they come in many flavors (associated, open, closed). Do we want to include all of the flavors? How do partial type families really operate? I wrote a blog post [1] exploring this topic and had more questions than answers. What about termination checking? Or do we want to allow non-terminating definitions and discard decidability of type inference?
>
> Of course, I recognize that John picked just a few arbitrary popular extensions. But even these extensions have a lot of dark corners, and my answers above are just to highlight that there's real work to be done, even with very popular extensions.
>
> Richard
>
> [1]: https://typesandkinds.wordpress.com/2015/09/09/what-are-type-families/
>
> On May 2, 2016, at 6:57 PM, "John Wiegley" <johnw at newartisans.com> wrote:
>
>> I wonder if there are GHC extensions we'd like to promote as features in the
>> next report, as a starting point for discussing new additions.
>>
>> There are a few GHC features that have become part of the regular Haskell
>> landscape, such that it's hard to imagine a modern Haskell without them. For
>> example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.
>>
>> How much "work" is typically involved in promoting a feature to be in the
>> Report, and how do we determine when it's a bad idea?
>>
>> --
>> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
>> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>> _______________________________________________
>> 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
>



-- 
Regards,

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

From gershomb at gmail.com  Tue May  3 03:44:03 2016
From: gershomb at gmail.com (Gershom B)
Date: Mon, 2 May 2016 23:44:03 -0400
Subject: Are there GHC extensions we'd like to incorporate
 wholesale?
In-Reply-To: <m2bn4orrtp.fsf@newartisans.com>
References: <m2bn4orrtp.fsf@newartisans.com>
Message-ID: <etPan.57281ebf.2e6841da.113@mbp.local>

I agree that GHC extensions should be the starting point for new additions, as changes to the report should be based on established implementations (to ensure that changes are implementable and to ensure that they work out well for users).

1) background reading

There were a few interesting threads on reddit the other day that may provide some fodder to think about.

First, there was a survey of what extensions that people found useful and would like incorporated, as well as their concerns:

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

(Feel free to disregard the confusion of how they described ?Haskell2016? and the like for something closer to glasgow-exts-2016, as its extraneous to what makes this interesting).

Second, the summary thread on the results:

https://www.reddit.com/r/haskell/comments/4ggp8z/summary_of_the_xhaskell2016_feedback/

The summary results give a good indication of what extensions there might seem to be the most widespread sentiment to standardize.

This thread also gives a link to Reid Barton?s lovely example of how FlexibleInstances can be used to violate coherence:?https://www.reddit.com/r/haskell/comments/2agy14/type_classes_confluence_coherence_global/civ6y1g

The same trick is supposed to apply to MPTCs. (In both cases, I imagine there can be a ?fixup? that would prevent this, but that?s for another discussion).

2) suggestions for proceeding

In any case, it seems to me (as a non-prime-committee member) that it would be good to proceed in two parallel tracks.

First: A victim^H^H^H^H^H^H volunteer to pick a particularly low-hanging fruit (lambdacase, tuple sections, binary literals) and try to do a test-run of the proposal process to work out the kinks and set an example for others to follow. Perhaps a few could be worked on by different people at once. (As a datapoint, here is I think how an accepted proposal looked under the H2010 process:?https://prime.haskell.org/wiki/NoNPlusKPatterns) (And I see that Austin has already volunteered! wonderful!)

Second: Some high-level effort to categorize and pull together a dependency graph of the other extensions. A googledoc spreadsheet or a trello board might be a good ?work arena? for this. I would want to separate extensions into for example buckets like ?pure syntax? ?typeclass related? ?monad syntax? ?deriving related? ?higher-rank related? ?record related? ?concurrency related?. The idea would be that things in the same bucket would have a higher chance of interacting / potentially needing to be treated in tandem. That way, areas could be tackled at once, and the committee could ?burndown? easy stuff, while perhaps individuals with expertise might want to try to work on the side to find ?minimal, safe? paths through the thicket of complex extensions. (standardizing GADT syntax without yet adding type equality constraints to enable actual GADTs is a good example here. Another _might_ be for example allowing RankNTypes but specifying that compliant compilers need only accept such type signatures fully specified, but could optionally go above and beyond in inference, etc). Note that more complex proposals could always be worked out by interest groups working by themselves, and only presented to a larger audience once some kinks were ironed out, etc.

Cheers,
Gershom



On May 2, 2016 at 6:57:46 PM, John Wiegley (johnw at newartisans.com) wrote:
> I wonder if there are GHC extensions we'd like to promote as features in the
> next report, as a starting point for discussing new additions.
>  
> There are a few GHC features that have become part of the regular Haskell
> landscape, such that it's hard to imagine a modern Haskell without them. For
> example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.  
>  
> How much "work" is typically involved in promoting a feature to be in the
> Report, and how do we determine when it's a bad idea?
>  
> --
> John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>  


From cgibbard at gmail.com  Tue May  3 05:28:25 2016
From: cgibbard at gmail.com (Cale Gibbard)
Date: Tue, 3 May 2016 01:28:25 -0400
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <etPan.57281ebf.2e6841da.113@mbp.local>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
Message-ID: <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>

This question implicitly has two parts:

1) Are there GHC extensions which the Report ought to describe in their
entirety? To this question, I would say "yes" - pretty much anything which
can be done in that direction will be productive, it's more a question of
what people are willing to put the work into.

2) Are there extensions which ought to stop being extensions? To this
question, I would argue it would be best to leave it for a time when the
extension is already fully described as an extension in the Report. It may
also be best to leave the answer up to the implementations. It is much
easier to argue for something like that once the extension has been on by
default in GHC and all other implementations for a while and most everyone
seems happy leaving it on.
On May 2, 2016 23:45, "Gershom B" <gershomb at gmail.com> wrote:

> I agree that GHC extensions should be the starting point for new
> additions, as changes to the report should be based on established
> implementations (to ensure that changes are implementable and to ensure
> that they work out well for users).
>
> 1) background reading
>
> There were a few interesting threads on reddit the other day that may
> provide some fodder to think about.
>
> First, there was a survey of what extensions that people found useful and
> would like incorporated, as well as their concerns:
>
>
> https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/
>
> (Feel free to disregard the confusion of how they described ?Haskell2016?
> and the like for something closer to glasgow-exts-2016, as its extraneous
> to what makes this interesting).
>
> Second, the summary thread on the results:
>
>
> https://www.reddit.com/r/haskell/comments/4ggp8z/summary_of_the_xhaskell2016_feedback/
>
> The summary results give a good indication of what extensions there might
> seem to be the most widespread sentiment to standardize.
>
> This thread also gives a link to Reid Barton?s lovely example of how
> FlexibleInstances can be used to violate coherence:
> https://www.reddit.com/r/haskell/comments/2agy14/type_classes_confluence_coherence_global/civ6y1g
>
> The same trick is supposed to apply to MPTCs. (In both cases, I imagine
> there can be a ?fixup? that would prevent this, but that?s for another
> discussion).
>
> 2) suggestions for proceeding
>
> In any case, it seems to me (as a non-prime-committee member) that it
> would be good to proceed in two parallel tracks.
>
> First: A victim^H^H^H^H^H^H volunteer to pick a particularly low-hanging
> fruit (lambdacase, tuple sections, binary literals) and try to do a
> test-run of the proposal process to work out the kinks and set an example
> for others to follow. Perhaps a few could be worked on by different people
> at once. (As a datapoint, here is I think how an accepted proposal looked
> under the H2010 process: https://prime.haskell.org/wiki/NoNPlusKPatterns)
> (And I see that Austin has already volunteered! wonderful!)
>
> Second: Some high-level effort to categorize and pull together a
> dependency graph of the other extensions. A googledoc spreadsheet or a
> trello board might be a good ?work arena? for this. I would want to
> separate extensions into for example buckets like ?pure syntax? ?typeclass
> related? ?monad syntax? ?deriving related? ?higher-rank related? ?record
> related? ?concurrency related?. The idea would be that things in the same
> bucket would have a higher chance of interacting / potentially needing to
> be treated in tandem. That way, areas could be tackled at once, and the
> committee could ?burndown? easy stuff, while perhaps individuals with
> expertise might want to try to work on the side to find ?minimal, safe?
> paths through the thicket of complex extensions. (standardizing GADT syntax
> without yet adding type equality constraints to enable actual GADTs is a
> good example here. Another _might_ be for example allowing RankNTypes but
> specifying that compliant compilers need only accept such type signatures
> fully specified, but could optionally go above and beyond in inference,
> etc). Note that more complex proposals could always be worked out by
> interest groups working by themselves, and only presented to a larger
> audience once some kinks were ironed out, etc.
>
> Cheers,
> Gershom
>
>
>
> On May 2, 2016 at 6:57:46 PM, John Wiegley (johnw at newartisans.com) wrote:
> > I wonder if there are GHC extensions we'd like to promote as features in
> the
> > next report, as a starting point for discussing new additions.
> >
> > There are a few GHC features that have become part of the regular Haskell
> > landscape, such that it's hard to imagine a modern Haskell without them.
> For
> > example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies,
> etc.
> >
> > How much "work" is typically involved in promoting a feature to be in the
> > Report, and how do we determine when it's a bad idea?
> >
> > --
> > John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
> > http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
> > _______________________________________________
> > 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/20160503/2b7c7b0a/attachment-0001.html>

From m.farkasdyck at gmail.com  Tue May  3 05:32:59 2016
From: m.farkasdyck at gmail.com (M Farkas-Dyck)
Date: Mon, 2 May 2016 21:32:59 -0800
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
Message-ID: <CAL3m8eDOhnzDDheZQTuyKLT8q_8P3zt1baBkFc1xeDfZG4EncA@mail.gmail.com>

On 02/05/2016, Cale Gibbard <cgibbard at gmail.com> wrote:
> Are there extensions which ought to stop being extensions?

> It may also be best to leave the answer up to the implementations. It is much
> easier to argue for something like that once the extension has been on by
> default in GHC and all other implementations for a while and most everyone
> seems happy leaving it on.

I think in many cases that would defeat the purpose of extensions.

From mail at andres-loeh.de  Tue May  3 06:12:58 2016
From: mail at andres-loeh.de (Andres Loeh)
Date: Tue, 3 May 2016 08:12:58 +0200
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <CAL3m8eDOhnzDDheZQTuyKLT8q_8P3zt1baBkFc1xeDfZG4EncA@mail.gmail.com>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
 <CAL3m8eDOhnzDDheZQTuyKLT8q_8P3zt1baBkFc1xeDfZG4EncA@mail.gmail.com>
Message-ID: <CALjd_v71+8JPsH1ExLknZh22SDG1yr-UaSNfO-GrnvUYZ0pBBQ@mail.gmail.com>

Hi.

Just to add a few general points. There are different dimensions to
evaluate GHC extensions for inclusion in the standard, and just making
lists does not really reflect that. The two most important ones, I
think, are:

1. Whether we think they're actually a good idea or not.

2. Whether we think they're feasible to specify in a sensible way.

There are variations of these points (extensions that are perhaps
possible to specify, but ugly in their current form; extensions that
have subtle interactions with others; ...)

In general, I am in favour on working on extensions for which we
believe they're good ideas, and try to make progress, even if we
cannot include them yet. So just as an example, if we think GADTs (and
not just GADTSyntax) are in principle a good idea and should be in a
future standard, then perhaps we can try to work out what exactly we
feel would be needed to include them, but is still missing. Then even
in times when no standardization process is active, people can look at
this list of issues and try to work on them. I also think that we
should be careful with straight-forward looking syntax extensions.
Just because an extension is easy to specify should not make it an
automatic accept either. The complexity of the language is already
high.

All this being said, I still have a personal list:

BangPatterns
ConstrainedClassMethods
ConstraintKinds (?)
Derive* (?)
EmptyCase
ExistentialQuantification
ExplicitForAll
ExplicitNamespaces
ExtendedDefaultRules (?)
FlexibleContexts
FlexibleInstances
GADTSyntax
InstanceSigs
KindSignatures
NullaryTypeClasses
Overloaded* (?)
PartialTypeSignatures (?)
RankNTypes
ScopedTypeVariables
StandaloneDeriving (?)
TypeSynonymInstances
TypeOperators (?)

I probably forgot a few. For the ones listed with (?), I am aware of
some problems, but I'd still be very happy to at least have some
discussions about them and make some progress in the direction of
future standardization, as I indicated above.

Cheers,
  Andres

On Tue, May 3, 2016 at 7:32 AM, M Farkas-Dyck <m.farkasdyck at gmail.com> wrote:
> On 02/05/2016, Cale Gibbard <cgibbard at gmail.com> wrote:
>> Are there extensions which ought to stop being extensions?
>
>> It may also be best to leave the answer up to the implementations. It is much
>> easier to argue for something like that once the extension has been on by
>> default in GHC and all other implementations for a while and most everyone
>> seems happy leaving it on.
>
> I think in many cases that would defeat the purpose of extensions.
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

From hvriedel at gmail.com  Tue May  3 07:10:45 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 03 May 2016 09:10:45 +0200
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <m2bn4orrtp.fsf@newartisans.com> (John Wiegley's message of "Mon, 
 02 May 2016 15:57:38 -0700")
References: <m2bn4orrtp.fsf@newartisans.com>
Message-ID: <8737pz39ca.fsf@gmail.com>

On 2016-05-03 at 00:57:38 +0200, John Wiegley wrote:
> I wonder if there are GHC extensions we'd like to promote as features
> in the next report, as a starting point for discussing new additions.
>
> There are a few GHC features that have become part of the regular
> Haskell landscape, such that it's hard to imagine a modern Haskell
> without them.

Btw, last year I computed a frequency-list of used extensions over
Hackage packages[1]. I'm planning to recompute such a list over all of
Hackage as well as over a Stackage subset. That would give us empirical
popularity data besides the subjective data provided by the recent
reddit discussion.

> For example, MultiParamTypeClasses, OverloadedStrings, GADTs,
> TypeFamilies, etc.
>
> How much "work" is typically involved in promoting a feature to be in the
> Report, and how do we determine when it's a bad idea?

As a concrete example of the problems formalising an extension, I'd like
to point to the example of 'BangPatterns' which may appear to be also
such a candidate and were considered for Haskell2014 already.

Back then, Ian hit some roadblocks:

  https://mail.haskell.org/pipermail/haskell-prime/2013-February/003782.html

Of course, I'm sure it would have been possible to resolve the open
issues with a bit more persistence. :-)


 [1]: https://gist.github.com/hvr/fd4fa2f10d4a10c7ebcc


-- hvr

From m.farkasdyck at gmail.com  Tue May  3 07:30:55 2016
From: m.farkasdyck at gmail.com (M Farkas-Dyck)
Date: Mon, 2 May 2016 23:30:55 -0800
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: <CAL3m8eCXz1GmpdNj6MzwjrrMN84mcbmA4qU0_NBW7+zpHdtt=g@mail.gmail.com>

On 29/04/2016, wren romano <wren at community.haskell.org> wrote:
> 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 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 agree on all these points.

I lean slightly towards Trac rather than Github myself, being a little
wary of enshrining other-party-hosted SaaS in a communal effort like
this, but i shan't make a fuss about it. I'm slightly against
Phabricator as installing PHP to work on Haskell feels very wrong.

From alexander at plaimi.net  Tue May  3 07:37:56 2016
From: alexander at plaimi.net (Alexander Berntsen)
Date: Tue, 3 May 2016 09:37:56 +0200
Subject: Infrastructure & Communication
In-Reply-To: <CAL3m8eCXz1GmpdNj6MzwjrrMN84mcbmA4qU0_NBW7+zpHdtt=g@mail.gmail.com>
References: <87pot9ieho.fsf@gmail.com> <20160429111540.GA22682@casa.casa>
 <57235EE1.80203@ciktel.net>
 <CABUjdS6ciar24nUVx=rvqwFQgmEZYuOpps8Tua_O_TQmMJWBuQ@mail.gmail.com>
 <CAL3m8eCXz1GmpdNj6MzwjrrMN84mcbmA4qU0_NBW7+zpHdtt=g@mail.gmail.com>
Message-ID: <57285554.2090108@plaimi.net>

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

On 03/05/16 09:30, M Farkas-Dyck wrote:
> I'm slightly against Phabricator as installing PHP to work on
> Haskell feels very wrong.
Try <https://github.com/haskell-infra/arc-lite>. YMMV.

FWIW, you'll likely need to use JavaScript regardless what choice is
made, so that's not much better. :)
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXKFVTAAoJENQqWdRUGk8BxfsQAO9OhV5GXCquyDtAnHGUMu9l
i/4VMW6HsV8GrQ+Hdlyj9UXwP72oS3liNQUtM7YTIkz8WuMIeqt8fnxEbx18l28d
zFj58LkC8QyvAg4Rtfxopw4KAHifEDCsK+aRbH0V7hVJxqwVKSthvgFyqpaPnJ4n
+T+1jYZthkCOuQh9gHdqZoD6s9dTCtfUvqWQgRtLQ8Z8tVB9rxVPQ/CO16Hq9wmK
KnppKsELCKxyuPz0P5m+biFj+WYLWSVZcyFSOHnjZO4ZKOQ1bvP8FVlv1iADLc5f
kU6sxy7aShZ8VXBO9CPneiYTt7ykchHCTcjXtYZMMWCjPe2RSQ+sfryzCMOq8Arl
G5jDOu4Az2QkG5vbfrxi8Z9+fHEm7Z0S+634P5khJnc/CcPmkYcGb/Dejq1qTbjG
rBUMc9mh/1LNHdyzvPujgi4jXp40NbBBfQ3yOm45Sk7LBPjnQSuj3/NI+arqgbw0
TeChg3phWD5X4VYxmmOFNZYFqaU07m0zDryrx/+iNUesDh2mnwksIKuVtA3iyHW5
HxhcuK2Ehii/Xk+OKJ80VssGd4ZuIXDI6CffIPaWbrt2TLIbwQUeKczR3n98Oy82
Dcmw1WZJC+kpfhb/SMOIcI4RIQCj5XSSwXWSXeN1js0GEQ56ZREQGZhxYI90bwPG
lC+QWGZ2gP8YUbIA/ISg
=4qAY
-----END PGP SIGNATURE-----

From m.farkasdyck at gmail.com  Tue May  3 08:03:45 2016
From: m.farkasdyck at gmail.com (M Farkas-Dyck)
Date: Tue, 3 May 2016 00:03:45 -0800
Subject: Infrastructure & Communication
In-Reply-To: <57285554.2090108@plaimi.net>
References: <87pot9ieho.fsf@gmail.com> <20160429111540.GA22682@casa.casa>
 <57235EE1.80203@ciktel.net>
 <CABUjdS6ciar24nUVx=rvqwFQgmEZYuOpps8Tua_O_TQmMJWBuQ@mail.gmail.com>
 <CAL3m8eCXz1GmpdNj6MzwjrrMN84mcbmA4qU0_NBW7+zpHdtt=g@mail.gmail.com>
 <57285554.2090108@plaimi.net>
Message-ID: <CAL3m8eBGOP+e5+VO7VWFQHom9zxN_6Y0TbDiVE_M+Zt6dpUivw@mail.gmail.com>

On 02/05/2016, Alexander Berntsen <alexander at plaimi.net> wrote:
> FWIW, you'll likely need to use JavaScript regardless what choice is
> made, so that's not much better. :)

Yes, but i'm already numb to that pain. PHP would be a fresh wound.

From simonpj at microsoft.com  Tue May  3 08:18:54 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 3 May 2016 08:18:54 +0000
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: <231d9913f6874aa4a0376bf7b2ac5a96@AM3PR30MB019.064d.mgd.msft.net>

|  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.

Andres says this well.  Being chair is a facilitating role, helping discussions make progress, and gently pressing them forward to a conclusion.  

I'm very grateful to Herbert for taking it on -- thank you!

Simon


|  -----Original Message-----
|  From: Haskell-prime [mailto:haskell-prime-bounces at haskell.org] On
|  Behalf Of Andres L?h
|  Sent: 30 April 2016 09:39
|  To: Herbert Valerio Riedel <hvriedel at gmail.com>
|  Cc: haskell-prime at haskell.org
|  Subject: Re: Chairship / responsibility
|  
|  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
|  

From Lennart.Augustsson at sc.com  Tue May  3 08:36:31 2016
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 3 May 2016 08:36:31 +0000
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <m2bn4orrtp.fsf@newartisans.com>
References: <m2bn4orrtp.fsf@newartisans.com>
Message-ID: <22B950C955F8AB4196E72698FBD00002D031F977@UKWPISXMB01B.zone1.scb.net>

I'd say there are extensions we should just adopt wholesale, but they are all of a very simple syntactic kind.
E.g., EmptyDataDecls, ExplicitNamespaces, KindSignatures(?), NamedFieldPuns (used be part of Haskell), RecordWildcards(?), TupleSections, TypeOperators.

-----Original Message-----
From: Haskell-prime [mailto:haskell-prime-bounces at haskell.org] On Behalf Of John Wiegley
Sent: 02 May 2016 23:58
To: haskell-prime at haskell.org
Subject: Are there GHC extensions we'd like to incorporate wholesale?

I wonder if there are GHC extensions we'd like to promote as features in the next report, as a starting point for discussing new additions.

There are a few GHC features that have become part of the regular Haskell landscape, such that it's hard to imagine a modern Haskell without them. For example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.

How much "work" is typically involved in promoting a feature to be in the Report, and how do we determine when it's a bad idea?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
_______________________________________________
Haskell-prime mailing list
Haskell-prime at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.

From hvriedel at gmail.com  Tue May  3 08:50:01 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 03 May 2016 10:50:01 +0200
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <22B950C955F8AB4196E72698FBD00002D031F977@UKWPISXMB01B.zone1.scb.net>
 (Lennart Augustsson's message of "Tue, 3 May 2016 08:36:31 +0000")
References: <m2bn4orrtp.fsf@newartisans.com>
 <22B950C955F8AB4196E72698FBD00002D031F977@UKWPISXMB01B.zone1.scb.net>
Message-ID: <87pot31q6e.fsf@gmail.com>

On 2016-05-03 at 10:36:31 +0200, Augustsson, Lennart wrote:

> I'd say there are extensions we should just adopt wholesale, but they
> are all of a very simple syntactic kind.
>
> E.g., EmptyDataDecls

Btw, I have no idea why EmptyDataDecls keeps getting proposed for
inclusion in the next report: `EmptyDataDecls` is one of the extensions
that went into Haskell2010! :-)

To quote Haskell2010, Ch. 12:

| Those implementations are also encouraged to support the following
| named language features:
| 
| - PatternGuards,
| - NoNPlusKPatterns,
| - RelaxedPolyRec,  
| - EmptyDataDecls,
| - ForeignFunctionInterface
| 
| These are the named language extensions supported by some pre-Haskell
| 2010 implementations, that have been integrated into this report.


There's actually a few more deltas to H98 (like e.g. DoAndIfThenElse), so

 {-# LANGUAGE Haskell2010 #-}

is not equivalent to

 {-# LANGUAGE Haskell98,
              PatternGuards, NoNPlusKPatterns, RelaxedPolyRec,  
              EmptyDataDecls, ForeignFunctionInterface #-}

But surprisingly this kind of information seems hard to find in the
H2010 report.


From Lennart.Augustsson at sc.com  Tue May  3 08:57:43 2016
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 3 May 2016 08:57:43 +0000
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <87pot31q6e.fsf@gmail.com>
References: <m2bn4orrtp.fsf@newartisans.com>
 <22B950C955F8AB4196E72698FBD00002D031F977@UKWPISXMB01B.zone1.scb.net>
 <87pot31q6e.fsf@gmail.com>
Message-ID: <22B950C955F8AB4196E72698FBD00002D031F9E2@UKWPISXMB01B.zone1.scb.net>

Then I suggest we keep EmptyDataDecls!

-----Original Message-----
From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] 
Sent: 03 May 2016 09:50
To: Augustsson, Lennart
Cc: John Wiegley; haskell-prime at haskell.org
Subject: Re: Are there GHC extensions we'd like to incorporate wholesale?

On 2016-05-03 at 10:36:31 +0200, Augustsson, Lennart wrote:

> I'd say there are extensions we should just adopt wholesale, but they 
> are all of a very simple syntactic kind.
>
> E.g., EmptyDataDecls

Btw, I have no idea why EmptyDataDecls keeps getting proposed for inclusion in the next report: `EmptyDataDecls` is one of the extensions that went into Haskell2010! :-)

To quote Haskell2010, Ch. 12:

| Those implementations are also encouraged to support the following 
| named language features:
| 
| - PatternGuards,
| - NoNPlusKPatterns,
| - RelaxedPolyRec,
| - EmptyDataDecls,
| - ForeignFunctionInterface
| 
| These are the named language extensions supported by some pre-Haskell
| 2010 implementations, that have been integrated into this report.


There's actually a few more deltas to H98 (like e.g. DoAndIfThenElse), so

 {-# LANGUAGE Haskell2010 #-}

is not equivalent to

 {-# LANGUAGE Haskell98,
              PatternGuards, NoNPlusKPatterns, RelaxedPolyRec,  
              EmptyDataDecls, ForeignFunctionInterface #-}

But surprisingly this kind of information seems hard to find in the
H2010 report.

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.

From iavor.diatchki at gmail.com  Tue May  3 16:14:46 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 3 May 2016 09:14:46 -0700
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <22B950C955F8AB4196E72698FBD00002D031F9E2@UKWPISXMB01B.zone1.scb.net>
References: <m2bn4orrtp.fsf@newartisans.com>
 <22B950C955F8AB4196E72698FBD00002D031F977@UKWPISXMB01B.zone1.scb.net>
 <87pot31q6e.fsf@gmail.com>
 <22B950C955F8AB4196E72698FBD00002D031F9E2@UKWPISXMB01B.zone1.scb.net>
Message-ID: <CAGK9nuoBr8dJtVRa=ytrju6vMExTkFrD8wkvKKaSD95x2enhag@mail.gmail.com>

Hello,

I think it'd be great to get started by specifying a few simple extensions,
such as the ones Lennart listed.  Even though they are very well
understood, and we have text about them in the GHC manual, we'd still have
to think of how to integrate their descriptions with the rest of the
report, and actually write the text.

I'd be happy to start working on any of these as soon as we've decided what
tools we'd like to use---I didn't follow the other thread closely, and I'd
be happy to use whatever people are comfortable with (as long as it works
on Linux, but I can't imagine that would be an issue).

-Iavor



On Tue, May 3, 2016 at 1:57 AM, Augustsson, Lennart <
Lennart.Augustsson at sc.com> wrote:

> Then I suggest we keep EmptyDataDecls!
>
> -----Original Message-----
> From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com]
> Sent: 03 May 2016 09:50
> To: Augustsson, Lennart
> Cc: John Wiegley; haskell-prime at haskell.org
> Subject: Re: Are there GHC extensions we'd like to incorporate wholesale?
>
> On 2016-05-03 at 10:36:31 +0200, Augustsson, Lennart wrote:
>
> > I'd say there are extensions we should just adopt wholesale, but they
> > are all of a very simple syntactic kind.
> >
> > E.g., EmptyDataDecls
>
> Btw, I have no idea why EmptyDataDecls keeps getting proposed for
> inclusion in the next report: `EmptyDataDecls` is one of the extensions
> that went into Haskell2010! :-)
>
> To quote Haskell2010, Ch. 12:
>
> | Those implementations are also encouraged to support the following
> | named language features:
> |
> | - PatternGuards,
> | - NoNPlusKPatterns,
> | - RelaxedPolyRec,
> | - EmptyDataDecls,
> | - ForeignFunctionInterface
> |
> | These are the named language extensions supported by some pre-Haskell
> | 2010 implementations, that have been integrated into this report.
>
>
> There's actually a few more deltas to H98 (like e.g. DoAndIfThenElse), so
>
>  {-# LANGUAGE Haskell2010 #-}
>
> is not equivalent to
>
>  {-# LANGUAGE Haskell98,
>               PatternGuards, NoNPlusKPatterns, RelaxedPolyRec,
>               EmptyDataDecls, ForeignFunctionInterface #-}
>
> But surprisingly this kind of information seems hard to find in the
> H2010 report.
>
> This email and any attachments are confidential and may also be
> privileged. If you are not the intended recipient, please delete all copies
> and notify the sender immediately. You may wish to refer to the
> incorporation details of Standard Chartered PLC, Standard Chartered Bank
> and their subsidiaries at
> http://www.standardchartered.com/en/incorporation-details.html
>
> Insofar as this communication contains any market commentary, the market
> commentary has been prepared by sales and/or trading desk of Standard
> Chartered Bank or its affiliate. It is not and does not constitute research
> material, independent research, recommendation or financial advice. Any
> market commentary is for information purpose only and shall not be relied
> for any other purpose, and is subject to the relevant disclaimers available
> at
> http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx
>
> Insofar as this e-mail contains the term sheet for a proposed transaction,
> by responding affirmatively to this e-mail, you agree that you have
> understood the terms and conditions in the attached term sheet and
> evaluated the merits and risks of the transaction. We may at times also
> request you to sign on the term sheet to acknowledge in respect of the same.
>
> Please visit
> http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
> for important information with respect to derivative products.
> _______________________________________________
> 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/20160503/1e082b58/attachment.html>

From doug at cs.dartmouth.edu  Tue May  3 18:04:41 2016
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 03 May 2016 14:04:41 -0400
Subject: Are there GHC extensions we'd like to incorporate wholesale?
Message-ID: <201605031804.u43I4fYH010448@coolidge.cs.Dartmouth.EDU>


> One objective would be to compile the Haskel Platform with near zero extensions.

I would hope that means that the platform will lean on contributors
to observe the new standard and curb exuberant use of extensions.
It would be wrong to blindly accept a selected corpus of existing
code as basis for a standard. (This is not to say that haskell prime
should ignore the practices of outstanding packages.)

Doug

From wren at community.haskell.org  Wed May  4 04:48:38 2016
From: wren at community.haskell.org (wren romano)
Date: Wed, 4 May 2016 00:48:38 -0400
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <CALjd_v71+8JPsH1ExLknZh22SDG1yr-UaSNfO-GrnvUYZ0pBBQ@mail.gmail.com>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
 <CAL3m8eDOhnzDDheZQTuyKLT8q_8P3zt1baBkFc1xeDfZG4EncA@mail.gmail.com>
 <CALjd_v71+8JPsH1ExLknZh22SDG1yr-UaSNfO-GrnvUYZ0pBBQ@mail.gmail.com>
Message-ID: <CABUjdS666Sm2XBF_tVL9dr2JNw3e_1OKROMnVt83kqUoAXVA6Q@mail.gmail.com>

On Tue, May 3, 2016 at 2:12 AM, Andres Loeh <mail at andres-loeh.de> wrote:
> Hi.
>
> Just to add a few general points. There are different dimensions to
> evaluate GHC extensions for inclusion in the standard, and just making
> lists does not really reflect that. The two most important ones, I
> think, are:
>
> 1. Whether we think they're actually a good idea or not.
>
> 2. Whether we think they're feasible to specify in a sensible way.
>
> There are variations of these points (extensions that are perhaps
> possible to specify, but ugly in their current form; extensions that
> have subtle interactions with others; ...)

I agree that these two points are what we should really be focusing on
(as well as things like ease of implementation), not just popularity.

For example, much as I love GADTs and would be all for them being
added in some future language report, I do not feel they should be
added this time around. (Though I emphatically and wholeheartedly
support adding GADTSyntax.) The primary reason being that while the
semantics of the data types themselves is easy enough to define,
there's no really sensible way of specifying how type inference should
work for them. GHC has gone back and forth with a bunch of different
inference methods over the years, and I don't think that's really
stabilized yet; so basically we'd be stuck with (a) not giving any
useful specification of what users can expect from inference / what
implementors must provide to be considered "standards compliant", or
(b) requiring some inference strategy that will stifle development
rather than help it.

Similarly, while TypeFamilies are fun to play with, I don't think
they're ready for primetime either. While in theory they are
equivalent to fundeps, in practice they're still playing catchup.
Given the choice, I'd much rather see fundeps be added to the spec,
where we make sure to phrase them in such a way that a viable
implementation could consider fundep syntax to be syntactic sugar for
some underlying story with TypeFamilies. ?As for whether I'd actually
be given that choice in the first place, I know there have been issues
in the past about adding fundeps to the report. So far as I know, the
main concern is that implementing them correctly is quite intricate
(as also reflected in the intricacies of getting things like
injectivity for TypeFamilies working). But, if we think it'd be a good
idea to aim for getting some variant of type families into the
standard in a future version, then the complexity of fundeps is
already required (if we're to have a complete story for where
TypeFamilies is currently headed). So adding fundeps now does help
towards the eventual goal of adding type families; even if one day we
think of fundeps as a funny syntactic sugar, like how some of us
already consider the ADT syntax to be a funny syntactic sugar for the
more straightforward GADTSyntax.



> All this being said, I still have a personal list:
>
> BangPatterns
> ConstrainedClassMethods
> ConstraintKinds (?)
> Derive* (?)
> EmptyCase
> ExistentialQuantification
> ExplicitForAll
> ExplicitNamespaces
> ExtendedDefaultRules (?)
> FlexibleContexts
> FlexibleInstances
> GADTSyntax
> InstanceSigs
> KindSignatures
> NullaryTypeClasses
> Overloaded* (?)
> PartialTypeSignatures (?)
> RankNTypes
> ScopedTypeVariables
> StandaloneDeriving (?)
> TypeSynonymInstances
> TypeOperators (?)
>
> I probably forgot a few. For the ones listed with (?), I am aware of
> some problems, but I'd still be very happy to at least have some
> discussions about them and make some progress in the direction of
> future standardization, as I indicated above.


Many of these are on my personal hit list as well. And most of the
ones that aren't still seem fine to add; the exceptions being:

TypeSynonymInstances ? I'm not a fan of this extension since it means
big warnings when teaching people Haskell (just getting them to
recognize that type-synonyms are mere shorthands and not generative
definitions is hard enough; any code using this extension requires
them to recognize that sooner). Though it people really want it...
::shrug::

ExtendedDefaultRules ? may be okay, but I haven't used/needed it so
have never thought about it.

FlexibleInstances ? I like this and want something very much like it,
but it's somewhat tricksy in practice so may need tweaking. In
particular, I've typically found that non-linear use of type variables
in the instance head is not in fact what people usually want/mean, and
so when such instances are given it leads to usability issues re
inference. Many times what is actually desired is to have a delayed
unification constraint, e.g. @instance (i ~ j) => Monad (IContT i j m)
where...@, where we first match the head (with only linear type
variables) and then after we've committed to selecting this instance
only then do we try to resolve the constraint. Even though the syntax
here is suggestive, I think we should be able to get away with adding
delayed unification constraints on instances without actually needing
any other type equality stuff that GHC does. While the problems I've
encountered with FlexibleInstances have mainly been due to non-linear
type variables, I could also see these delayed unification constraints
being helpful for the portion of FlexibleInstances which allows
non-variables to occur in argument positions; again because matching
on the top-level constructor of the instance head may be enough to
help us ground out the arguments to that constuctor, and we really
want to do that grounding after committing to using the instance
rather than as part of deciding whether to use the instance or not.

Overloaded* ? If these are added I'd much rather have these as
"standard language extensions", i.e., they would still need to be
explicitly turned on, rather than being enabled everywhere. While it's
nice to have these extensions available, I very seldom need them, and
in light of that am a bit concerned about a backlash similar to the
one with the FTP.

Speaking of which, are things like the AMP and FTP under our purview
or are they under the CLC?

-- 
Live well,
~wren

From m.farkasdyck at gmail.com  Wed May  4 05:00:28 2016
From: m.farkasdyck at gmail.com (M Farkas-Dyck)
Date: Tue, 3 May 2016 21:00:28 -0800
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
Message-ID: <CAL3m8eDAzRuSq8eZxj1px9LaVgcAmj2QtUajAY3OTq+oP3ugBQ@mail.gmail.com>

On 02/05/2016, Cale Gibbard <cgibbard at gmail.com> wrote:
> This question implicitly has two parts:
>
> 1) Are there GHC extensions which the Report ought to describe in their
> entirety? ...
>
> 2) Are there extensions which ought to stop being extensions? ...

I agree here, except as noted in my earlier mail in this thread.

An extension i might like to no longer be an extension is
NoMonomorphismRestriction, which i haven't yet seen brought up in this
thread. I recognize it has some rationale for it, but i surely want
this committee to at least re-evaluate its merits.

From dominique.devriese at cs.kuleuven.be  Wed May  4 06:51:26 2016
From: dominique.devriese at cs.kuleuven.be (Dominique Devriese)
Date: Wed, 04 May 2016 06:51:26 +0000
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <CAL3m8eDAzRuSq8eZxj1px9LaVgcAmj2QtUajAY3OTq+oP3ugBQ@mail.gmail.com>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
 <CAL3m8eDAzRuSq8eZxj1px9LaVgcAmj2QtUajAY3OTq+oP3ugBQ@mail.gmail.com>
Message-ID: <CAML5wvsyye-xttoSXHXy4yFneVqF3MgHziogGA8jq5WwviDG3w@mail.gmail.com>

As an outsider, I would like to suggest thinking about MonoLocalBinds.  GHC
has a rather convincing story (at least to me) that "(local) let should not
be generalised" (since it becomes problematic in combination with several
other language extensions) and the journal version of the OutsideIn(X)
paper has empirical data that indicates it is not a big problem to remove.
If there is a concern about backwards compatibility, perhaps the committee
could deprecate local let generalisation in Haskell2020 and remove it in a
subsequent iteration of the report?

Regards,
Dominique

Op wo 4 mei 2016 om 07:00 schreef M Farkas-Dyck <m.farkasdyck at gmail.com>:

> On 02/05/2016, Cale Gibbard <cgibbard at gmail.com> wrote:
> > This question implicitly has two parts:
> >
> > 1) Are there GHC extensions which the Report ought to describe in their
> > entirety? ...
> >
> > 2) Are there extensions which ought to stop being extensions? ...
>
> I agree here, except as noted in my earlier mail in this thread.
>
> An extension i might like to no longer be an extension is
> NoMonomorphismRestriction, which i haven't yet seen brought up in this
> thread. I recognize it has some rationale for it, but i surely want
> this committee to at least re-evaluate its merits.
> _______________________________________________
> 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/20160504/9c59beae/attachment-0001.html>

From hvriedel at gmail.com  Wed May  4 07:23:50 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Wed, 04 May 2016 09:23:50 +0200
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <CABUjdS666Sm2XBF_tVL9dr2JNw3e_1OKROMnVt83kqUoAXVA6Q@mail.gmail.com>
 (wren romano's message of "Wed, 4 May 2016 00:48:38 -0400")
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
 <CAL3m8eDOhnzDDheZQTuyKLT8q_8P3zt1baBkFc1xeDfZG4EncA@mail.gmail.com>
 <CALjd_v71+8JPsH1ExLknZh22SDG1yr-UaSNfO-GrnvUYZ0pBBQ@mail.gmail.com>
 <CABUjdS666Sm2XBF_tVL9dr2JNw3e_1OKROMnVt83kqUoAXVA6Q@mail.gmail.com>
Message-ID: <87eg9imgl5.fsf@gmail.com>

On 2016-05-04 at 06:48:38 +0200, wren romano wrote:

[...]

> Speaking of which, are things like the AMP and FTP under our purview
> or are they under the CLC?

I tried to clarify in the call-for-nomination and the formation
announcement that the library part of the Haskell Report shall be
formally under the CL(i)C's purview given their experience with
designing and implementing the big AMP/FTP/MFP proposals. In fact, I'd
like to think of the (extended) Prime Committee as being composed of two
sub-committee's: CLiC & CLaC (i.e. the Core Library Committee and Core
Language Committee). This gives each sub-committee a clear focus.

Of course, there'll sometimes be interactions (like
e.g. language-extensions/features to improve backward compatibility with
Haskell2010) between the language and the library part, so CLiC & CLaC
will have to talk to each other from time to time. It's also quite
possible that CLaC members may pick-up work-items from the CLiC or
vice-versa.

I know some of you consider the "Prelude" module as being morally a part
of the "language" rather than the library. But I'm sure the CLiC will
exercise extreme caution when the holy-grail "Prelude" module happens to
require adaptations and keep everyone in the loop. Not the least because
somebody may have alternative ideas how to achieve the goal differently
worth considering.

-- hvr

From simonpj at microsoft.com  Wed May  4 07:50:29 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 4 May 2016 07:50:29 +0000
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <CABUjdS666Sm2XBF_tVL9dr2JNw3e_1OKROMnVt83kqUoAXVA6Q@mail.gmail.com>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
 <CAL3m8eDOhnzDDheZQTuyKLT8q_8P3zt1baBkFc1xeDfZG4EncA@mail.gmail.com>
 <CALjd_v71+8JPsH1ExLknZh22SDG1yr-UaSNfO-GrnvUYZ0pBBQ@mail.gmail.com>
 <CABUjdS666Sm2XBF_tVL9dr2JNw3e_1OKROMnVt83kqUoAXVA6Q@mail.gmail.com>
Message-ID: <48f2bdc7255e4c01aa66c13527c30445@DB4PR30MB030.064d.mgd.msft.net>

|  For example, much as I love GADTs and would be all for them being added
|  in some future language report, I do not feel they should be added this
|  time around. (Though I emphatically and wholeheartedly support adding
|  GADTSyntax.) The primary reason being that while the semantics of the
|  data types themselves is easy enough to define, there's no really
|  sensible way of specifying how type inference should work for them. GHC
|  has gone back and forth with a bunch of different inference methods
|  over the years, and I don't think that's really stabilized yet;

Actually it has stabilised.  The OutsideIn journal paper (http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/index.htm) describes how it works, and has been absolutely stable for several years.  (All the movement has been on other things: type families, kind polymorphism, etc.)

I agree that the specification isn't entirely satisfactory, because it's a bit operational.  But it's robust and stable.

I'm not arguing for or against GADTs in the next iteration of Haskell.  But I don't think that the ease or difficulty of specifying GADTs is going to change much, so waiting till next time may not help; useful as they are, a declarative specification for GADTs is tricky.


Simon


From Henrik.Nilsson at nottingham.ac.uk  Wed May  4 08:21:03 2016
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Wed, 04 May 2016 09:21:03 +0100
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <48f2bdc7255e4c01aa66c13527c30445@DB4PR30MB030.064d.mgd.msft.net>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
 <CAL3m8eDOhnzDDheZQTuyKLT8q_8P3zt1baBkFc1xeDfZG4EncA@mail.gmail.com>
 <CALjd_v71+8JPsH1ExLknZh22SDG1yr-UaSNfO-GrnvUYZ0pBBQ@mail.gmail.com>
 <CABUjdS666Sm2XBF_tVL9dr2JNw3e_1OKROMnVt83kqUoAXVA6Q@mail.gmail.com>
 <48f2bdc7255e4c01aa66c13527c30445@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <5729B0EF.30006@nottingham.ac.uk>

Hi all,

 > For example, much as I love GADTs and would be all for them being
 > added in some future language report, I do not feel they should be
 > added this time around. (Though I emphatically and wholeheartedly
 > support adding GADTSyntax.)

In my opinion, GADTs is one of the most important extensions of the
Haskell type system over the past decade and definitely a sweet spot
in the design space in terms of power vs. complexity, at least from
a user perspective. I eagerly await Herbert's summary of of most used
extensions (which I think will be an extremely important input when
deciding how to go forward in general), but my definite impression is
that GADTs (and not just GADT syntax) are used a lot.

Point taken about the difficulty of specifying GADT type inference
declaratively. But as long as there at least is a way to standardise
inference that works, and from what Simon said there is, I do think
aiming to make GADTs an official part of Haskell 2020 should be a
priority.

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 eir at cis.upenn.edu  Wed May  4 12:57:48 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 4 May 2016 08:57:48 -0400
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <5729B0EF.30006@nottingham.ac.uk>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
 <CAL3m8eDOhnzDDheZQTuyKLT8q_8P3zt1baBkFc1xeDfZG4EncA@mail.gmail.com>
 <CALjd_v71+8JPsH1ExLknZh22SDG1yr-UaSNfO-GrnvUYZ0pBBQ@mail.gmail.com>
 <CABUjdS666Sm2XBF_tVL9dr2JNw3e_1OKROMnVt83kqUoAXVA6Q@mail.gmail.com>
 <48f2bdc7255e4c01aa66c13527c30445@DB4PR30MB030.064d.mgd.msft.net>
 <5729B0EF.30006@nottingham.ac.uk>
Message-ID: <D9D19E8C-30F2-4B00-A70E-5E7FBA428E30@cis.upenn.edu>

There are many points I'd like to make in this discussion, but this one screams out the loudest:

This thread is spiraling a bit out of control. I've seen useful conversations around many different extensions in here, but these conversations are sometimes only tangentially related. I'd personally much rather see us decide on a tool/process first, and then we can have someplace to have The GADT Discussion and another place to have The Overloaded Discussion, etc. Otherwise, we risk losing good points in this thread, and someone will have to comb through all of this to extract these good points.

The discussion about what our goals are w.r.t. extensions -- whether to consider popularity, ease of specification, ease of implementation, making standard extensions, etc -- is, to me, more appropriate for this thread and this point in the process.

So, might I humbly request that we focus our collective creative energies on having a stable process before getting into nitty-gritty details about extensions?

Thanks,
Richard

On May 4, 2016, at 4:21 AM, Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk> wrote:

> Hi all,
> 
> > For example, much as I love GADTs and would be all for them being
> > added in some future language report, I do not feel they should be
> > added this time around. (Though I emphatically and wholeheartedly
> > support adding GADTSyntax.)
> 
> In my opinion, GADTs is one of the most important extensions of the
> Haskell type system over the past decade and definitely a sweet spot
> in the design space in terms of power vs. complexity, at least from
> a user perspective. I eagerly await Herbert's summary of of most used
> extensions (which I think will be an extremely important input when
> deciding how to go forward in general), but my definite impression is
> that GADTs (and not just GADT syntax) are used a lot.
> 
> Point taken about the difficulty of specifying GADT type inference
> declaratively. But as long as there at least is a way to standardise
> inference that works, and from what Simon said there is, I do think
> aiming to make GADTs an official part of Haskell 2020 should be a
> priority.
> 
> 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


From christian at siefkes.net  Wed May  4 09:35:53 2016
From: christian at siefkes.net (Christian Siefkes)
Date: Wed, 4 May 2016 11:35:53 +0200
Subject: Starting point for new standard?
Message-ID: <5729C279.4040602@siefkes.net>

Hi all,

out of curiosity, what'll be the starting point for the next Haskell report?
I suppose Haskell 2010 plus the additional "No Datatype Contexts" change
accepted by the old Haskell Language committee in early 2011 (see
https://wiki.haskell.org/Haskell_2010#Additional_change )?

Best regards
        Christian

-- 
|--------- Dr. Christian Siefkes --------- christian at siefkes.net ---------
| Homepage:   http://www.siefkes.net/   |   Blog:   http://www.keimform.de/
| Wie Produktion zur Nebensache wurde: www.keimform.de/2013/freie-quellen-1/
| Why Production No Longer Worries Us: www.keimform.de/2013/free-sources-1/
|------------------------------------------- OpenPGP Key ID: 0x980FA6ED --
2 + 2 = 5 for suitably large values of 2.


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

From jmct at jmct.cc  Wed May  4 21:41:09 2016
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Wed, 4 May 2016 17:41:09 -0400
Subject: Starting point for new standard?
In-Reply-To: <5729C279.4040602@siefkes.net>
References: <5729C279.4040602@siefkes.net>
Message-ID: <CAK+ijdtHjB35O612LqDxTV3Dg13Z1Wx=RrUM2oV=voXkWyYRHA@mail.gmail.com>

Hello Christian,

On Wed, May 4, 2016 at 5:35 AM, Christian Siefkes <christian at siefkes.net> wrote:
> Hi all,
>
> out of curiosity, what'll be the starting point for the next Haskell report?
> I suppose Haskell 2010 plus the additional "No Datatype Contexts" change
> accepted by the old Haskell Language committee in early 2011 (see
> https://wiki.haskell.org/Haskell_2010#Additional_change )?

It hasn't been stated explicitly, but I would expect you're mostly correct.

The library portion of the standard is now under the purview of the
Core Libraries Committee (CLC) [1]. Therefore the current Haskell
Standard takes into account their work in addition to what you've
mentioned.

There's another thread on the mailing list about which extensions
deserve to be promoted to language features which might interest you,
but as far as I'm aware the assumed foundation is the 2010 report and
the work of the CLC.

Cheers,

Jose

[1]: https://wiki.haskell.org/Core_Libraries_Committee

From carter.schonwald at gmail.com  Thu May  5 03:53:14 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 4 May 2016 23:53:14 -0400
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <D9D19E8C-30F2-4B00-A70E-5E7FBA428E30@cis.upenn.edu>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
 <CAL3m8eDOhnzDDheZQTuyKLT8q_8P3zt1baBkFc1xeDfZG4EncA@mail.gmail.com>
 <CALjd_v71+8JPsH1ExLknZh22SDG1yr-UaSNfO-GrnvUYZ0pBBQ@mail.gmail.com>
 <CABUjdS666Sm2XBF_tVL9dr2JNw3e_1OKROMnVt83kqUoAXVA6Q@mail.gmail.com>
 <48f2bdc7255e4c01aa66c13527c30445@DB4PR30MB030.064d.mgd.msft.net>
 <5729B0EF.30006@nottingham.ac.uk>
 <D9D19E8C-30F2-4B00-A70E-5E7FBA428E30@cis.upenn.edu>
Message-ID: <CAHYVw0wdCH-FNWQfyQ18OuVwqyXC62_eX_zox-qLGhoYe=e7mA@mail.gmail.com>

Well said, having coherent location to collect bits per topic so they don't
get lost to mailing list thread mists of time is pretty important. I don't
care too much as long as it's easy to comment on a topic / ticket and or
propose edits. But probably something we should front load doing.

On Wednesday, May 4, 2016, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> There are many points I'd like to make in this discussion, but this one
> screams out the loudest:
>
> This thread is spiraling a bit out of control. I've seen useful
> conversations around many different extensions in here, but these
> conversations are sometimes only tangentially related. I'd personally much
> rather see us decide on a tool/process first, and then we can have
> someplace to have The GADT Discussion and another place to have The
> Overloaded Discussion, etc. Otherwise, we risk losing good points in this
> thread, and someone will have to comb through all of this to extract these
> good points.
>
> The discussion about what our goals are w.r.t. extensions -- whether to
> consider popularity, ease of specification, ease of implementation, making
> standard extensions, etc -- is, to me, more appropriate for this thread and
> this point in the process.
>
> So, might I humbly request that we focus our collective creative energies
> on having a stable process before getting into nitty-gritty details about
> extensions?
>
> Thanks,
> Richard
>
> On May 4, 2016, at 4:21 AM, Henrik Nilsson <
> Henrik.Nilsson at nottingham.ac.uk <javascript:;>> wrote:
>
> > Hi all,
> >
> > > For example, much as I love GADTs and would be all for them being
> > > added in some future language report, I do not feel they should be
> > > added this time around. (Though I emphatically and wholeheartedly
> > > support adding GADTSyntax.)
> >
> > In my opinion, GADTs is one of the most important extensions of the
> > Haskell type system over the past decade and definitely a sweet spot
> > in the design space in terms of power vs. complexity, at least from
> > a user perspective. I eagerly await Herbert's summary of of most used
> > extensions (which I think will be an extremely important input when
> > deciding how to go forward in general), but my definite impression is
> > that GADTs (and not just GADT syntax) are used a lot.
> >
> > Point taken about the difficulty of specifying GADT type inference
> > declaratively. But as long as there at least is a way to standardise
> > inference that works, and from what Simon said there is, I do think
> > aiming to make GADTs an official part of Haskell 2020 should be a
> > priority.
> >
> > Best,
> >
> > /Henrik
> >
> > --
> > Henrik Nilsson
> > School of Computer Science
> > The University of Nottingham
> > nhn at cs.nott.ac.uk <javascript:;>
> >
> >
> >
> >
> > 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 <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/20160504/3afb3920/attachment.html>

From alexander at plaimi.net  Fri May  6 13:09:57 2016
From: alexander at plaimi.net (Alexander Berntsen)
Date: Fri, 6 May 2016 15:09:57 +0200
Subject: Limber separators
Message-ID: <572C97A5.3050308@plaimi.net>

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

Haskell uses separators for values in a number of syntactic
constructs. It is my understanding of the 2010 report that the
language does however not generally support leading separators, nor
trailing separators, nor both (two exceptions are discussed at the end
of this email). Consequently diffs are bloated, resulting in mental
overhead when viewing and reviewing patches, as well as potential
three-way merge conflicts or worse. A quick example:

[ Foo
, Bar
, Fu
, Baz
]

It is impossible to remove values Foo or Baz with a one line diff. It
is additionally impossible to reasonably add a new value to the top or
bottom of the list.

I want the Haskell' committee to discuss allowing one or more of the
following:

* Leading separators
* Trailing separators
* No separators

The former two, or a combination, is arguably the least invasive
modification, whilst the latter is more sensible as a language
extension for now as it would break code. The latter is furthermore
difficult as the rules are potentially more involved, yielding more
gotchas. My immediate suggestion for the no separators route would be
to use newlines.

The discussion should apply to as many contexts as deemed sensible. It
is arguably insensible to introduce leading or trailing separators
where we would end up with ambiguity, as would be the case with tuple
declarations due to tuple sections. Examples of where it would be
sensible are abundant, and include -- but aren't limited to -- data
types, lists, record fields, pattern guards, and language pragmas.

If leading separators, or trailing separators, or both, are accepted
as the way to go forward, perhaps permit extra separators in general.
I.e. [,,,Foo,,,Bar,,,Fu,,,Baz,,,] is a list with four terms, Foo, Bar,
Fu, and Baz.


Please note that Haskell 2010 already permits trailing commas in
import and export lists, like so:

impspec ? ( import1 , ? , importn [ , ] ) (n ? 0)
exports ? ( export1 , ? , exportn [ , ] ) (n ? 0)

Meaning the following is legal:

import Foo (
  Fu,
  Baz,
)

And the following:

module Foo (
  Fu,
  Baz,
)

Bizarrely, the following is *not* legal:

import Foo (
  Bar (
    Fu,
    Baz,
  )
)

I.e. impspecs are permitted trailing commas, imports aren't.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXLJekAAoJENQqWdRUGk8BksEQANHIhsGRaoDuwb6CM3NapElv
XfcSgW5//Vva0/8f//BXUvN2rrfadxcjzr4xKL8CKME9sxlgRJ56RQi+Ai/L0mNZ
h1x0Uqi3dmDzMxF1ROgKlUMjU4CAGqq5MMl3iZTC4vP7NpMUrqodZe7zO9INnP/7
av0x9GPI1SnXc1xocSMew9VA1fzd1tr8e+M73tex1yNC1pr5vI5hKSliofwTBHhW
BAIKVOu3hEBUjhziZkmSPqOZJ4QCJYsMQ6P6ZCnxs7K2vplA3OQC+jOO/vM6MqdZ
iaRrYiqyof3XkeNr7/Z96+6/iKdGIGn4+OsOzrWUMdsJfY/kftb7KJR/tRgfWug9
QMlMjmTfxDkCAlonU2uNwSustcMTJNhq6g4Ymg6k5t7MwojT6dDE0ASAUlOKGbCk
WRvDVLRGaQcn7HF4PWq7RnrP+lvl9OUZr36L4QZrG8ei5v2DN/H30hlT0zzbyp97
yO9yHQZ0TmCt+iAbDi822vRlmfJEH7zRkrsmcHAmiOAsAfvZoaqtSiLK2eiczb1g
V7h1h1ze3i0I+MNf7+Sbzot3kJwW8+3XqZoh2B1oyWgiDlrZhLDDHaEY4yzoPG3E
hdmAOoYx43tnd6LkWhar86CwoxelyKvpXoLNp6JZe+mUAG4qwoa8AIcXglk4KTty
k0M1NEwiPSy+/ymABx/T
=E+MY
-----END PGP SIGNATURE-----

From m.farkasdyck at gmail.com  Fri May  6 16:32:18 2016
From: m.farkasdyck at gmail.com (M Farkas-Dyck)
Date: Fri, 6 May 2016 08:32:18 -0800
Subject: Infrastructure & Communication
In-Reply-To: <87pot9ieho.fsf@gmail.com>
References: <87pot9ieho.fsf@gmail.com>
Message-ID: <CAL3m8eBV9VzdowUHxamWVw87wggdHEG1GsjvjBpgiD30rBeYoQ@mail.gmail.com>

I think we ought to make a choice quite soon. Proposals are already
being made on this list, but i hesitate to make comment lest it be
forgotten when we move to our new medium.

My opinion on our choice of medium is known, i believe. Who or what
makes the final call? hvr? committee member votes?

From iavor.diatchki at gmail.com  Fri May  6 16:34:46 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 6 May 2016 09:34:46 -0700
Subject: Limber separators
In-Reply-To: <572C97A5.3050308@plaimi.net>
References: <572C97A5.3050308@plaimi.net>
Message-ID: <CAGK9nurBPKnzepOoBR_rtODovjR3Tt4PQJ8V=U8FGFUh1Wd02w@mail.gmail.com>

Hello,

I am not convinced by the argument that this will help make 'diffs'
considerably simpler: we have tools for visualizing diffs, and saving an
extra line at the beginning/end of a long enumeration seems like an
unlikely source of confusion or serious merge conflicts.

By the way, leading/trailing separators conflict with the syntax for tuple
sections:

(True,) :: t -> (Bool, t)
(,True) :: t -> (t, Bool)

I think that it wold be quite odd if leading/trailing commas meant one
thing in tuples and something completely different in lists.

-Iavor



On Fri, May 6, 2016 at 6:09 AM, Alexander Berntsen <alexander at plaimi.net>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Haskell uses separators for values in a number of syntactic
> constructs. It is my understanding of the 2010 report that the
> language does however not generally support leading separators, nor
> trailing separators, nor both (two exceptions are discussed at the end
> of this email). Consequently diffs are bloated, resulting in mental
> overhead when viewing and reviewing patches, as well as potential
> three-way merge conflicts or worse. A quick example:
>
> [ Foo
> , Bar
> , Fu
> , Baz
> ]
>
> It is impossible to remove values Foo or Baz with a one line diff. It
> is additionally impossible to reasonably add a new value to the top or
> bottom of the list.
>
> I want the Haskell' committee to discuss allowing one or more of the
> following:
>
> * Leading separators
> * Trailing separators
> * No separators
>
> The former two, or a combination, is arguably the least invasive
> modification, whilst the latter is more sensible as a language
> extension for now as it would break code. The latter is furthermore
> difficult as the rules are potentially more involved, yielding more
> gotchas. My immediate suggestion for the no separators route would be
> to use newlines.
>
> The discussion should apply to as many contexts as deemed sensible. It
> is arguably insensible to introduce leading or trailing separators
> where we would end up with ambiguity, as would be the case with tuple
> declarations due to tuple sections. Examples of where it would be
> sensible are abundant, and include -- but aren't limited to -- data
> types, lists, record fields, pattern guards, and language pragmas.
>
> If leading separators, or trailing separators, or both, are accepted
> as the way to go forward, perhaps permit extra separators in general.
> I.e. [,,,Foo,,,Bar,,,Fu,,,Baz,,,] is a list with four terms, Foo, Bar,
> Fu, and Baz.
>
>
> Please note that Haskell 2010 already permits trailing commas in
> import and export lists, like so:
>
> impspec ? ( import1 , ? , importn [ , ] ) (n ? 0)
> exports ? ( export1 , ? , exportn [ , ] ) (n ? 0)
>
> Meaning the following is legal:
>
> import Foo (
>   Fu,
>   Baz,
> )
>
> And the following:
>
> module Foo (
>   Fu,
>   Baz,
> )
>
> Bizarrely, the following is *not* legal:
>
> import Foo (
>   Bar (
>     Fu,
>     Baz,
>   )
> )
>
> I.e. impspecs are permitted trailing commas, imports aren't.
> - --
> Alexander
> alexander at plaimi.net
> https://secure.plaimi.net/~alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCgAGBQJXLJekAAoJENQqWdRUGk8BksEQANHIhsGRaoDuwb6CM3NapElv
> XfcSgW5//Vva0/8f//BXUvN2rrfadxcjzr4xKL8CKME9sxlgRJ56RQi+Ai/L0mNZ
> h1x0Uqi3dmDzMxF1ROgKlUMjU4CAGqq5MMl3iZTC4vP7NpMUrqodZe7zO9INnP/7
> av0x9GPI1SnXc1xocSMew9VA1fzd1tr8e+M73tex1yNC1pr5vI5hKSliofwTBHhW
> BAIKVOu3hEBUjhziZkmSPqOZJ4QCJYsMQ6P6ZCnxs7K2vplA3OQC+jOO/vM6MqdZ
> iaRrYiqyof3XkeNr7/Z96+6/iKdGIGn4+OsOzrWUMdsJfY/kftb7KJR/tRgfWug9
> QMlMjmTfxDkCAlonU2uNwSustcMTJNhq6g4Ymg6k5t7MwojT6dDE0ASAUlOKGbCk
> WRvDVLRGaQcn7HF4PWq7RnrP+lvl9OUZr36L4QZrG8ei5v2DN/H30hlT0zzbyp97
> yO9yHQZ0TmCt+iAbDi822vRlmfJEH7zRkrsmcHAmiOAsAfvZoaqtSiLK2eiczb1g
> V7h1h1ze3i0I+MNf7+Sbzot3kJwW8+3XqZoh2B1oyWgiDlrZhLDDHaEY4yzoPG3E
> hdmAOoYx43tnd6LkWhar86CwoxelyKvpXoLNp6JZe+mUAG4qwoa8AIcXglk4KTty
> k0M1NEwiPSy+/ymABx/T
> =E+MY
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20160506/de67f045/attachment.html>

From alexander at plaimi.net  Fri May  6 16:52:10 2016
From: alexander at plaimi.net (Alexander Berntsen)
Date: Fri, 6 May 2016 18:52:10 +0200
Subject: Limber separators
In-Reply-To: <CAGK9nurBPKnzepOoBR_rtODovjR3Tt4PQJ8V=U8FGFUh1Wd02w@mail.gmail.com>
References: <572C97A5.3050308@plaimi.net>
 <CAGK9nurBPKnzepOoBR_rtODovjR3Tt4PQJ8V=U8FGFUh1Wd02w@mail.gmail.com>
Message-ID: <572CCBBA.1090300@plaimi.net>

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

On 06/05/16 18:34, Iavor Diatchki wrote:
> I am not convinced by the argument that this will help make 'diffs'
>  considerably simpler: we have tools for visualizing diffs,
Most people I know read plaintext patches in emails. Others use things
like home made review tools, built-in review tools on SaaSS platforms
like GitHub, review tools in big systems like Phabricator or Gitolite,
etc. None of these help.

> and saving an extra line at the beginning/end of a long enumeration
>  seems like an unlikely source of confusion
The examples I gave were banal. More involved ones are easily
imagined. Moreover, if you view things in isolation like this then
everything is simple and clear, so I think it is an unfair argument.

> or serious merge conflicts.
I don't know what you mean by "serious", but I don't treasure any
moment I've spent on solving three-way merges from this issue.


> By the way, leading/trailing separators conflict with the syntax
> for tuple sections:
> 
> (True,) :: t -> (Bool, t) (,True) :: t -> (t, Bool)
Please read my email; I already mention this.

> I think that it wold be quite odd if leading/trailing commas meant
>  one thing in tuples and something completely different in lists.
As explained in the original email: there is already precedent for
trailing commas in import and export lists, so commas already mean
something different there. Commas are overloaded already. I don't find
this any more confusing than ad-hoc polymorphism in general.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXLMu5AAoJENQqWdRUGk8BSW0QAKgX1VIZyH+TA5b7Ac0ieZmn
8gwVeIB+rFog8TqZ/KSF4aY3kO92M35FFvFI0BV3YEaE+URW42S2r5MgtpvQBiCt
cudVW2SHZU9BAag1vU1cd8vykFwLphxZQ+/bRidKRM3+zebK6a8ON6cJTPXOrM3W
bo2s95ZjGnYkkuT+cMEXBD6V193aNJZGFWF4PnN7OBFt0u1w3Lm0ZhTH1qewQMZP
PypTlFVL6N45sWDPKqbTlrb0vES25AWNGdMjHZi5UkQ3Wv0IB8rxiEnxR4VUFe6v
8Wy/xLSnutSk+Lgz68HnoztYNrvQVwpBjRDuhpv/1QhcKedY2/daLAt9u2tBEdBs
9RpzViGI1GNexRo8obztUV4zuFHE+F8vCf4ovCoGZSUMHWM0iGjEJzPXSGvcq2Bn
tt+b0TZfH/kpUirlfkONiEHDHKANBBI2pdfsc+yqxSPfTL4wU/aTLRGbwazT26de
N5MQI5Q77kXlDjEM+2YkuD9YDWX28/LJWtUwMsAYqkrRYX+Xn7/YzpEz4M7En8SE
UWL62RXnX9BCF64Gl9GhlPnXUq8J/gTrz3iehTbKhABD+W6Ew+zpGbvMGAjz8da3
gUtOAgvKdUlvfJlE+Whr99Df3dnju43cKHeu9iTPiGbI5tkomVUMETexCO+D90BC
gsSwLod24dVNh91/7Yxk
=oHX2
-----END PGP SIGNATURE-----

From dluposchainsky at googlemail.com  Fri May  6 17:22:04 2016
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Fri, 6 May 2016 19:22:04 +0200
Subject: Limber separators
In-Reply-To: <572C97A5.3050308@plaimi.net>
References: <572C97A5.3050308@plaimi.net>
Message-ID: <572CD2BC.6000906@gmail.com>

I frequently run into the (relatively minor) list comma problem when writing
testsuites. I'd welcome a grammar change that simply skips all commas before "]"
and after "[" or similar.

I think this issue is related to TupleSections in that Haskell does not provide
good syntax for these common cases. However, as mentioned, we should be careful
to introduce syntax for convenience: without a principled approach, we'll end up
with sugar soup.

I for one need "-XTailingListCommas" much more often than tuple sections, so when
weighing those extensions against each other, I'm very much on the list side.

Just for confirmation, you meant

> [ Foo
> , Bar
> , Fu
> , Baz ]

and not

> [ Foo
> , Bar
> , Fu
> , Baz
> ]

in your email, right?

Greetings,
David/quchen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160506/b4adbb4a/attachment.sig>

From alexander at plaimi.net  Fri May  6 19:45:31 2016
From: alexander at plaimi.net (Alexander Berntsen)
Date: Fri, 6 May 2016 21:45:31 +0200
Subject: Limber separators
In-Reply-To: <572CD2BC.6000906@gmail.com>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
Message-ID: <572CF45B.7060109@plaimi.net>

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

On 06/05/16 19:22, David Luposchainsky wrote:
> Just for confirmation, you meant
> 
>> > [ Foo
>> > , Bar
>> > , Fu
>> > , Baz ]
> and not
> 
>> > [ Foo
>> > , Bar
>> > , Fu
>> > , Baz
>> > ]
> in your email, right?
Yes. The latter is how I have adapted my style to be able to remove Baz
in a one-line diff, so I wrote it automatically. :)

Similarly, this fixes the removal/addition problem for the top
element, but not the bottom element:

[
Foo,
Bar,
Fu,
Baz
]
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXLPRaAAoJENQqWdRUGk8BBGQQALQVQftrgJrCxWDtgvo43ZGZ
NmBrBCDBVwwKojBq8HgHF6oOK2tQhglu1KefQtX7Qrya8UxtM/axI/AU38jnrHHq
19zQBzyEpiAoGgbd/02OkoWvyj+fDt2dy5KI6PV74BnKnZ2k6ZmpYcffRXuL/Cdb
4zUZ2FTpU2FSx0HE0FTfdETqZ5dwjIEyBWiHd+eqEEQgTO7KUc6Q10jqkw6xeVuI
EVIbZNh9/n4bl2cJEHpgQ/442w21Neg5gMJWc/5UCnhpBwJUhYtxJRJWRqfgJQ1E
zM2pI1gkJZbTqiL/YinxbFAkXVF2CGMjLMdUH8gANPuPaI7FYz1F5kydmjuIuxwP
I4bE9hdDnDzTnClPzgryfNBc2EcMdK91sG3+/qBRP/SGlTzttUciQo44dR42Zi5s
/qEx0vmtOy5Meh3PSAUs2kkMcvS7ELFKQlXfzxNR0pKYFN5cwAUTcSPLqEtNfG7M
D/K0k76F99+Ehhl2aralO2TntSj8qZN5AeOa/YndKQE3xiqVcnVKUJ34mOba5N2u
FcpuV9jF1kt3+t5EQUWar2x56jwcqnLE3rPu4Hj3qzL3R5hAyJYh/yDPEVOgxo8W
7B+uS0IBCMmiCOeJv3HqGGkLTywzzLjka4X3nQHVK0aYu4gNgfEJLg2vbA9K1KJB
+6ig1u87MQx4HfDyL/57
=00Rx
-----END PGP SIGNATURE-----

From cgibbard at gmail.com  Fri May  6 19:58:36 2016
From: cgibbard at gmail.com (Cale Gibbard)
Date: Fri, 6 May 2016 15:58:36 -0400
Subject: Limber separators
In-Reply-To: <572CF45B.7060109@plaimi.net>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
Message-ID: <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>

I can't really be the only one here who thinks that this kind of
discussion of extensions to the syntax of Haskell is totally
inappropriate when we have a large number of already implemented
extensions to the language whose interactions with each other are
largely undocumented. The Haskell Report isn't the place to be talking
about new features, in my mind. If this project turns into
bike-shedding the concrete syntax of the language, it's hard to
imagine real progress being made on the actual problem, which is that
the Haskell Reports as they stand are not as relevant as they should
be with regard to the language in which we're writing programs today.

In my opinion, this sort of bikeshed discussion of new features is the
main reason that H2010 didn't really get very far relative to H98.

If you personally want the ability to insert additional commas at the
beginning or end of lists, perhaps a better plan is to start with
asking the GHC developers with where to begin on a patch to the
parser. Then once everyone is using your extension, some future
Haskell Report can perhaps document it.

I'm sorry if this comes off as harsh, and I don't really mean to be
picking on Alexander specifically here, but I'd really like for the
next Haskell Report to be relevant to the language we're using today,
and I think there's too much to be done in the direction of reporting
on the things we already have to even consider things which are
unimplemented, or even things which were only *just* implemented.

On 6 May 2016 at 15:45, Alexander Berntsen <alexander at plaimi.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 06/05/16 19:22, David Luposchainsky wrote:
>> Just for confirmation, you meant
>>
>>> > [ Foo
>>> > , Bar
>>> > , Fu
>>> > , Baz ]
>> and not
>>
>>> > [ Foo
>>> > , Bar
>>> > , Fu
>>> > , Baz
>>> > ]
>> in your email, right?
> Yes. The latter is how I have adapted my style to be able to remove Baz
> in a one-line diff, so I wrote it automatically. :)
>
> Similarly, this fixes the removal/addition problem for the top
> element, but not the bottom element:
>
> [
> Foo,
> Bar,
> Fu,
> Baz
> ]
> - --
> Alexander
> alexander at plaimi.net
> https://secure.plaimi.net/~alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCgAGBQJXLPRaAAoJENQqWdRUGk8BBGQQALQVQftrgJrCxWDtgvo43ZGZ
> NmBrBCDBVwwKojBq8HgHF6oOK2tQhglu1KefQtX7Qrya8UxtM/axI/AU38jnrHHq
> 19zQBzyEpiAoGgbd/02OkoWvyj+fDt2dy5KI6PV74BnKnZ2k6ZmpYcffRXuL/Cdb
> 4zUZ2FTpU2FSx0HE0FTfdETqZ5dwjIEyBWiHd+eqEEQgTO7KUc6Q10jqkw6xeVuI
> EVIbZNh9/n4bl2cJEHpgQ/442w21Neg5gMJWc/5UCnhpBwJUhYtxJRJWRqfgJQ1E
> zM2pI1gkJZbTqiL/YinxbFAkXVF2CGMjLMdUH8gANPuPaI7FYz1F5kydmjuIuxwP
> I4bE9hdDnDzTnClPzgryfNBc2EcMdK91sG3+/qBRP/SGlTzttUciQo44dR42Zi5s
> /qEx0vmtOy5Meh3PSAUs2kkMcvS7ELFKQlXfzxNR0pKYFN5cwAUTcSPLqEtNfG7M
> D/K0k76F99+Ehhl2aralO2TntSj8qZN5AeOa/YndKQE3xiqVcnVKUJ34mOba5N2u
> FcpuV9jF1kt3+t5EQUWar2x56jwcqnLE3rPu4Hj3qzL3R5hAyJYh/yDPEVOgxo8W
> 7B+uS0IBCMmiCOeJv3HqGGkLTywzzLjka4X3nQHVK0aYu4gNgfEJLg2vbA9K1KJB
> +6ig1u87MQx4HfDyL/57
> =00Rx
> -----END PGP SIGNATURE-----
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

From alexander at plaimi.net  Fri May  6 20:04:19 2016
From: alexander at plaimi.net (Alexander Berntsen)
Date: Fri, 6 May 2016 22:04:19 +0200
Subject: Limber separators
In-Reply-To: <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
Message-ID: <572CF8C3.5080301@plaimi.net>

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

On 06/05/16 21:58, Cale Gibbard wrote:
> I can't really be the only one here who thinks that this kind of 
> discussion of extensions to the syntax of Haskell is totally 
> inappropriate when we have a large number of already implemented 
> extensions to the language whose interactions with each other are 
> largely undocumented.
I agree that there are more important milestones for Haskell' than
this. I disagree that anything but those more important milestones
should be shot down as somehow inappropriate. Especially given the
time frame of four years.

> I'm sorry if this comes off as harsh, and I don't really mean to
> be picking on Alexander specifically here
I'd like to add that I don't think you're coming off as harsh or as if
you're picking on me. :)
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXLPjCAAoJENQqWdRUGk8BlIYQAKYhnSPwSufX/FqPnl3D4pRR
QocLkPjacydJQFcy2RbJYRM5UwSw1/Cs/a78zjnuy4dK6a5uH5DkG8w6ObljbvCn
0vbsj92FpDVtzmcNQt6rvfcMPD8sjzc4rR+6kTysYsVm1k3zARwO94IykVApUXy0
SMtH7DxPT4SyGr/07xA6T1c7SYn2if85aAM2DTdqgN78iJzyJAlxpitMAUSkwsuf
bIbi0ZM0leDPxgbGN5IsV/8TI21r5oymFj4L2nUWz0WfD6lrNUJemXgKzuVUHL1q
WOxvF4Ngv5HpGuF08UmyNWxhiIkR6cfFbx+KqeBtdensOLiPDNwTP56mmbqSsH+i
OrJuG8UTVpEK4EYLfm9KWOWCbznM9FpJ6QXU9hGnxBteG1rF8bXbZJiCefATw5pr
TMq/+StpToI0rJPGLPFBJAbKhaBG2pj9RbiPO67vpkkPdvIgqgEzSyC6MxuFTu3g
kkPpifadb2WUJKmqlXaK9wcIut1dJun1juA5d4NMjgabB+1wodra35HSF6oKwTp6
FqiOJphwvegSw5xGv04D9S28ymme+C2oB713yDtFqFxcMTDwGG+8vHCDYckxzpqe
m+fEYZsVgQpV5/8ybJs47unrGdn0ZMPBf/iEf/63ifoLGqAOYI0QMswnuRJ7wD3o
14Hng6xTt4MsQqBbKGvw
=saV3
-----END PGP SIGNATURE-----

From spam at scientician.net  Fri May  6 20:04:03 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Fri, 6 May 2016 22:04:03 +0200
Subject: Limber separators
In-Reply-To: <CAGK9nurBPKnzepOoBR_rtODovjR3Tt4PQJ8V=U8FGFUh1Wd02w@mail.gmail.com>
References: <572C97A5.3050308@plaimi.net>
 <CAGK9nurBPKnzepOoBR_rtODovjR3Tt4PQJ8V=U8FGFUh1Wd02w@mail.gmail.com>
Message-ID: <ngitbj$5t4$1@ger.gmane.org>

On 05/06/2016 06:34 PM, Iavor Diatchki wrote:
[--snip--]
> By the way, leading/trailing separators conflict with the syntax for tuple
> sections:
> 
> (True,) :: t -> (Bool, t)
> (,True) :: t -> (t, Bool)
> 
> I think that it wold be quite odd if leading/trailing commas meant one
> thing in tuples and something completely different in lists.
> 
[--snip--]

(I'm not on the committee or even close, just be absolutely clear from
the start.)

While I have a) *NEVER*... *EVER* seen TupleSections in the wild[1], and
b) I really, really want to have an "ignore-trailing-comma" rule for
lists, I must say that this is a situation where backward-compat and the
Principle of Least Surpise[2] probably rule the day.

I'm certainly be open to persuasion, but that would probably mean
deprecating TupleSections, and I'm not sure how popular that would be.
(And would perhaps require *two* iterations of the Haskell standard to
achieve. I suppose an exception could be made if a "go fix" type tool
could be developed, but I'm not sure that's something the Standards
committe should concern themselves with... but it *would* be able to
move the language towards much faster evolution, FWIW. I wish we had hfix.)

Regards,

[1] Didn't even know they existed until the recent thread on Reddit.

[2] That is, it would be surprising if lists and tuples worked
differently in this respect.




From spam at scientician.net  Fri May  6 20:14:19 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Fri, 6 May 2016 22:14:19 +0200
Subject: Limber separators
In-Reply-To: <572CF8C3.5080301@plaimi.net>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
 <572CF8C3.5080301@plaimi.net>
Message-ID: <ngitur$d5s$1@ger.gmane.org>

On 05/06/2016 10:04 PM, Alexander Berntsen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 06/05/16 21:58, Cale Gibbard wrote:
>> I can't really be the only one here who thinks that this kind of 
>> discussion of extensions to the syntax of Haskell is totally 
>> inappropriate when we have a large number of already implemented 
>> extensions to the language whose interactions with each other are 
>> largely undocumented.
> I agree that there are more important milestones for Haskell' than
> this. I disagree that anything but those more important milestones
> should be shot down as somehow inappropriate. Especially given the
> time frame of four years.

+1.

The existense of "THE GREATEST PROBLEM IN THE WORLD" doesn't mean that
we cannot try to solve "SMALL PROBLEM". (This is a classic fallacy.)

Regards,


From dct25-561bs at mythic-beasts.com  Sat May  7 08:24:00 2016
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Sat, 7 May 2016 09:24:00 +0100
Subject: Limber separators
In-Reply-To: <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
Message-ID: <CAErCyQ8KHfZbhk-FtBC6urwrj-5VAkQ=7AVcC1bOMOgkaAsTeQ@mail.gmail.com>

On 6 May 2016 20:58, "Cale Gibbard" <cgibbard at gmail.com> wrote:
>
> If you personally want the ability to insert additional commas at the
> beginning or end of lists, perhaps a better plan is to start with
> asking the GHC developers with where to begin on a patch to the
> parser. Then once everyone is using your extension, some future
> Haskell Report can perhaps document it.

+1

I would use this extension. But I strongly agree that it should start out
as an  extension and prove its worth in that form before becoming part of
the language proper. Having Haskell' choose from the set of all available
extensions is already a daunting task without opening the gates on
unimplemented things too!

I get the impression that many extensions that merely extend the syntax of
the language are widely considered to be acceptable and seem to be on track
for inclusion in H'. If this were implemented soon enough, perhaps it can
make it in this time too; if not then I'm sure it'd be a candidate for a
future report.

I use TupleSections, and would prefer that this extension did not apply to
tuples. I would also prefer to get rid of the separators completely and
just use layout to delimit things, somehow.

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

From jon.fairbairn at cl.cam.ac.uk  Sat May  7 08:44:21 2016
From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn)
Date: Sat, 07 May 2016 09:44:21 +0100
Subject: Limber separators
References: <572C97A5.3050308@plaimi.net>
Message-ID: <wfh9eantp6.fsf@calligramme.charmers>


Alexander Berntsen
<alexander at plaimi.net> writes:
> [ Foo
> , Bar
> , Fu
> , Baz ]
>
> It is impossible to remove values Foo or Baz with a one line diff. It
> is additionally impossible to reasonably add a new value to the top or
> bottom of the list.

I?m not on the committee either, but here?s my three haporth.

Something that is missing from this type of discussion is any
reference to design rules, agreement on which should be made
before any suggestion like this.

The one this violates is ?never make language design decisions
to work around deficiencies in tools? The problem is that diff
does its work in ignorance of the syntax and consequently
produces poor results.

The other observation I want to make is that the object of
programming language design is not to make writing programmes
(or changing) easier. It is to make writing incorrect programmes
(especially programmes that look right but are not) harder. We
have to ask whether making a ?one line diff? do this is actually
productive. Having a large Hamming distance between
syntactically valid programmes is an advantage.

-- 
J?n Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk


From spam at scientician.net  Sat May  7 11:30:25 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Sat, 7 May 2016 13:30:25 +0200
Subject: Limber separators
In-Reply-To: <ngitbj$5t4$1@ger.gmane.org>
References: <572C97A5.3050308@plaimi.net>
 <CAGK9nurBPKnzepOoBR_rtODovjR3Tt4PQJ8V=U8FGFUh1Wd02w@mail.gmail.com>
 <ngitbj$5t4$1@ger.gmane.org>
Message-ID: <ngkjki$mfn$1@ger.gmane.org>

On 05/06/2016 10:04 PM, Bardur Arantsson wrote:

> 
[--snip--]

Actually, thinking about it a little further... TupleSections is already
opt-in, so this needn't conflict per se.

Regards,


From alexander at plaimi.net  Sat May  7 11:35:36 2016
From: alexander at plaimi.net (Alexander Berntsen)
Date: Sat, 7 May 2016 13:35:36 +0200
Subject: Limber separators
In-Reply-To: <wfh9eantp6.fsf@calligramme.charmers>
References: <572C97A5.3050308@plaimi.net> <wfh9eantp6.fsf@calligramme.charmers>
Message-ID: <572DD308.6080404@plaimi.net>

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

On 07/05/16 10:44, Jon Fairbairn wrote:
> Something that is missing from this type of discussion is any 
> reference to design rules, agreement on which should be made before
> any suggestion like this.
> 
> The one this violates is ?never make language design decisions to
> work around deficiencies in tools?
I am entirely sympathetic to the argument. But I also have to read and
write Haskell a lot, and to suffer from something that can seemingly
be so trivially fixed *hurts*. Especially when languages like F# and
Elm have taken a more practical stance and just fixed it. It's another
"Haskell isn't practical/serious" argument from engineers -- and like
it or not, engineers are the main users of the language.

We should definitely avoid success at all costs. However, I don't
think the cost is too great in this instance. Especially considering
that there is already precedent for this in import and export lists.

Finally, I'd like to add that I appreciate your post and angle, and
hope that the committee take it to heart in general. The design should
be guided by (but not slave to) first principles.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXLdMHAAoJENQqWdRUGk8BRZkQAOcxrn2oBuJMZkOsDN3vN4z7
GkeDbf4N6EB//xeQxWYvGkzcFoVLsKY6CASZ4pthRKEn0hE7EgP8q7MZOuoTECt8
fvECtpL50v43GFQ8aY6thytKkPWIPuhaN9gL5jrH5S/Q5dS4cieaxEqdh27RBSYZ
FFiLlOrpVPQcuIzo2EVVVReApbatNIu3LsUXWW0wLeEjqudEVRt4yLK6WMAdSdKO
C5OMuZoU2G0Cw4LOQV5tDnUfj9RS06+AJIEUUvgk7xbhU46ZaNQHqde1pTDJ3w/K
Iq3g5WFndt8JZfAN/2eTLCmWj4EsX/iBMDunQqwlmAxlez5qYIgNlnlB9a7guj/n
9BT9zLuxnc/SsKB33KIkFSlVyQsssBXWOqvRcQ6ND4yi26rTLJry0WvEZ5IDmdg+
hRdKKb2YvyHLBuqMp7rIBQ7fwfCegWfJpp4A+GsCbkKXfz2SZJCBdDT3UZMkgwIQ
qXr4CRESKssGXh/ezz+vXltxTAPArfDb97vULr8PeIrMoBFacIR6PVhSxHS7aSeE
Hbh7zD6S6ynobtFBReQo4KYGlXUOC9nNDktnpjUAc12xQoRwVqirAasJ5D1oMwkO
LB6L6YyHVlfcqb8ZfbFAHpblCCrbuw4f3pi6a9YVUy4d9ZyhX0K0RFSEWcHxE1rG
yWFHxsMF+/bf7AM+tX9z
=/DKF
-----END PGP SIGNATURE-----

From _deepfire at feelingofgreen.ru  Sat May  7 13:34:01 2016
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Sat, 07 May 2016 16:34:01 +0300
Subject: Limber separators
In-Reply-To: <ngkjki$mfn$1@ger.gmane.org>
 (sfid-20160507_160141_354390_C1259816) (Bardur Arantsson's message of
 "Sat, 7 May 2016 13:30:25 +0200")
References: <572C97A5.3050308@plaimi.net>
 <CAGK9nurBPKnzepOoBR_rtODovjR3Tt4PQJ8V=U8FGFUh1Wd02w@mail.gmail.com>
 <ngitbj$5t4$1@ger.gmane.org> <ngkjki$mfn$1@ger.gmane.org>
Message-ID: <87k2j6kn5i.fsf@feelingofgreen.ru>

Bardur Arantsson <spam at scientician.net> writes:
> Actually, thinking about it a little further... TupleSections is already
> opt-in, so this needn't conflict per se.

Isn't this dangerous, in how it now gives a trivial piece of code
two very different interpretations, in a plausibly unintentional way?

> {-# LANGUAGE TupleSections #-}
> (x, y, ) :: t -> (a, b, t)

> {-# LANGUAGE LaxCommas #-}
> (x, y, ) :: (a, b)

I understand that we have OverloadedStrings, viz:

> {-# LANGUAGE NoOverloadedStrings #-}
> "a" :: [Char]

> {-# LANGUAGE OverloadedStrings #-}
> "a" :: IsString a => a

and yet, the differences in this respect seems significant:

The unintentionality of change in interpretation effected by the
transition NoOverloadedStrings -> OverloadedStrings is implausible.

Whereas with the LaxCommas -> TupleSections transition I guess it would
be fair to say that it is plausible.

Moreover, OverloadedStrings doesn't disallow using string literals as
string literals, whereas LaxCommas and TupleSections are mutually
exclusive.

-- 
? ???????e? / respectfully,
??????? ??????

From carter.schonwald at gmail.com  Sat May  7 15:38:31 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 7 May 2016 11:38:31 -0400
Subject: Limber separators
In-Reply-To: <87k2j6kn5i.fsf@feelingofgreen.ru>
References: <572C97A5.3050308@plaimi.net>
 <CAGK9nurBPKnzepOoBR_rtODovjR3Tt4PQJ8V=U8FGFUh1Wd02w@mail.gmail.com>
 <ngitbj$5t4$1@ger.gmane.org> <ngkjki$mfn$1@ger.gmane.org>
 <87k2j6kn5i.fsf@feelingofgreen.ru>
Message-ID: <CAHYVw0z0XJ-XiucsXfEWEoNG16CiCS=-n7TnrqH5Q_MScT5zow@mail.gmail.com>

I worry that this thread is turning into a bit of bike shed before we have
a good sense of what construction tools we have on hand!

One side consideration we might want to keep in mind is what spaces of
parser tech can work off the shelf in various juxtapositions of code and
features.

The more context sensitive a grammar is, the more humans Pay too!

I've certainly seen agressive amounts of tuple sections in industrial code.


Another meta question / challenge that this thread has posed is : given
Haskell as it is today / will be in the future, is there a meaningfully
better language tuned diff tool that could exist ?

On Saturday, May 7, 2016, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote:

> Bardur Arantsson <spam at scientician.net <javascript:;>> writes:
> > Actually, thinking about it a little further... TupleSections is already
> > opt-in, so this needn't conflict per se.
>
> Isn't this dangerous, in how it now gives a trivial piece of code
> two very different interpretations, in a plausibly unintentional way?
>
> > {-# LANGUAGE TupleSections #-}
> > (x, y, ) :: t -> (a, b, t)
>
> > {-# LANGUAGE LaxCommas #-}
> > (x, y, ) :: (a, b)
>
> I understand that we have OverloadedStrings, viz:
>
> > {-# LANGUAGE NoOverloadedStrings #-}
> > "a" :: [Char]
>
> > {-# LANGUAGE OverloadedStrings #-}
> > "a" :: IsString a => a
>
> and yet, the differences in this respect seems significant:
>
> The unintentionality of change in interpretation effected by the
> transition NoOverloadedStrings -> OverloadedStrings is implausible.
>
> Whereas with the LaxCommas -> TupleSections transition I guess it would
> be fair to say that it is plausible.
>
> Moreover, OverloadedStrings doesn't disallow using string literals as
> string literals, whereas LaxCommas and TupleSections are mutually
> exclusive.
>
> --
> ? ???????e? / respectfully,
> ??????? ??????
> _______________________________________________
> 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/20160507/d28d73e4/attachment.html>

From carter.schonwald at gmail.com  Sat May  7 15:46:20 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 7 May 2016 11:46:20 -0400
Subject: Limber separators
In-Reply-To: <CAHYVw0z0XJ-XiucsXfEWEoNG16CiCS=-n7TnrqH5Q_MScT5zow@mail.gmail.com>
References: <572C97A5.3050308@plaimi.net>
 <CAGK9nurBPKnzepOoBR_rtODovjR3Tt4PQJ8V=U8FGFUh1Wd02w@mail.gmail.com>
 <ngitbj$5t4$1@ger.gmane.org> <ngkjki$mfn$1@ger.gmane.org>
 <87k2j6kn5i.fsf@feelingofgreen.ru>
 <CAHYVw0z0XJ-XiucsXfEWEoNG16CiCS=-n7TnrqH5Q_MScT5zow@mail.gmail.com>
Message-ID: <CAHYVw0y=NQ=B0zWSon9Dd8ypZm1z7W3mq80hTDsKwb_8_Dc1jg@mail.gmail.com>

On Saturday, May 7, 2016, Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> I worry that this thread is turning into a bit of bike shed before we have
> a good sense of what construction tools we have on hand!
>
> One side consideration we might want to keep in mind is what spaces of
> parser tech can work off the shelf in various juxtapositions of code and
> features.
>
> The more context sensitive a grammar is, the more humans Pay too!
>
> I've certainly seen agressive amounts of tuple sections in industrial
> code.
>
> Another meta question / challenge that this thread has posed is : given
> Haskell as it is today / will be in the future, is there a meaningfully
> better language tuned diff tool that could exist ?
>
>
>
> On Saturday, May 7, 2016, Kosyrev Serge <_deepfire at feelingofgreen.ru
> <javascript:_e(%7B%7D,'cvml','deepfire at feelingofgreen.ru');>> wrote:
>
>> Bardur Arantsson <spam at scientician.net> writes:
>> > Actually, thinking about it a little further... TupleSections is already
>> > opt-in, so this needn't conflict per se.
>>
>> Isn't this dangerous, in how it now gives a trivial piece of code
>> two very different interpretations, in a plausibly unintentional way?
>>
>> > {-# LANGUAGE TupleSections #-}
>> > (x, y, ) :: t -> (a, b, t)
>>
>> > {-# LANGUAGE LaxCommas #-}
>> > (x, y, ) :: (a, b)
>>
>> I understand that we have OverloadedStrings, viz:
>>
>> > {-# LANGUAGE NoOverloadedStrings #-}
>> > "a" :: [Char]
>>
>> > {-# LANGUAGE OverloadedStrings #-}
>> > "a" :: IsString a => a
>>
>> and yet, the differences in this respect seems significant:
>>
>> The unintentionality of change in interpretation effected by the
>> transition NoOverloadedStrings -> OverloadedStrings is implausible.
>>
>> Whereas with the LaxCommas -> TupleSections transition I guess it would
>> be fair to say that it is plausible.
>>
>> Moreover, OverloadedStrings doesn't disallow using string literals as
>> string literals, whereas LaxCommas and TupleSections are mutually
>> exclusive.
>>
>> --
>> ? ???????e? / respectfully,
>> ??????? ??????
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>


My bad for forgetting to reply below rather than above :)

Tla+ does have leading AND style syntax in the style of the  what is being
discussed here, but that was done from the outset.

Either way, experiments in syntax and semantics are best grounded in ...
Running experiments using them!  Certainly some parts of what we hope to
achieve need to be grounded thusly, even if it's not changing the type
system or the syntax of the core substrate.  Let's do some experimental
research and see what happens in the wild, in codes natural habitats! ??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160507/6ca6f443/attachment.html>

From eir at cis.upenn.edu  Sat May  7 20:05:47 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 7 May 2016 16:05:47 -0400
Subject: Infrastructure & Communication
In-Reply-To: <CAL3m8eBV9VzdowUHxamWVw87wggdHEG1GsjvjBpgiD30rBeYoQ@mail.gmail.com>
References: <87pot9ieho.fsf@gmail.com>
 <CAL3m8eBV9VzdowUHxamWVw87wggdHEG1GsjvjBpgiD30rBeYoQ@mail.gmail.com>
Message-ID: <98AADAEC-AC9D-4E91-9E4B-A0BAB6D5AB6D@cis.upenn.edu>

I second this motion to call a vote or other concrete, forward-moving action on this topic.

I, too, am refraining from commenting on other threads until this issue is resolved.

Richard

On May 6, 2016, at 12:32 PM, M Farkas-Dyck <m.farkasdyck at gmail.com> wrote:

> I think we ought to make a choice quite soon. Proposals are already
> being made on this list, but i hesitate to make comment lest it be
> forgotten when we move to our new medium.
> 
> My opinion on our choice of medium is known, i believe. Who or what
> makes the final call? hvr? committee member votes?
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


From bravit111 at gmail.com  Sat May  7 20:22:49 2016
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Sat, 07 May 2016 20:22:49 +0000
Subject: Infrastructure & Communication
In-Reply-To: <98AADAEC-AC9D-4E91-9E4B-A0BAB6D5AB6D@cis.upenn.edu>
References: <87pot9ieho.fsf@gmail.com>
 <CAL3m8eBV9VzdowUHxamWVw87wggdHEG1GsjvjBpgiD30rBeYoQ@mail.gmail.com>
 <98AADAEC-AC9D-4E91-9E4B-A0BAB6D5AB6D@cis.upenn.edu>
Message-ID: <CALpVSmP_0Azh9nBz+MhQtHSp_YerWTq9yMOz9sDLa2noh21xaw@mail.gmail.com>

The third one here. I think that process decisions can be made by chairman
alone without calling votes, that's organizing part of job, not conceptual
one.

Vitaly

On Sat, May 7, 2016 at 10:05 PM Richard Eisenberg <eir at cis.upenn.edu> wrote:

> I second this motion to call a vote or other concrete, forward-moving
> action on this topic.
>
> I, too, am refraining from commenting on other threads until this issue is
> resolved.
>
> Richard
>
> On May 6, 2016, at 12:32 PM, M Farkas-Dyck <m.farkasdyck at gmail.com> wrote:
>
> > I think we ought to make a choice quite soon. Proposals are already
> > being made on this list, but i hesitate to make comment lest it be
> > forgotten when we move to our new medium.
> >
> > My opinion on our choice of medium is known, i believe. Who or what
> > makes the final call? hvr? committee member votes?
> > _______________________________________________
> > 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/20160507/5491c52e/attachment-0001.html>

From carter.schonwald at gmail.com  Sat May  7 20:33:57 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 7 May 2016 16:33:57 -0400
Subject: Infrastructure & Communication
In-Reply-To: <CALpVSmP_0Azh9nBz+MhQtHSp_YerWTq9yMOz9sDLa2noh21xaw@mail.gmail.com>
References: <87pot9ieho.fsf@gmail.com>
 <CAL3m8eBV9VzdowUHxamWVw87wggdHEG1GsjvjBpgiD30rBeYoQ@mail.gmail.com>
 <98AADAEC-AC9D-4E91-9E4B-A0BAB6D5AB6D@cis.upenn.edu>
 <CALpVSmP_0Azh9nBz+MhQtHSp_YerWTq9yMOz9sDLa2noh21xaw@mail.gmail.com>
Message-ID: <CAHYVw0xRHKYjJ+Pi_0dXbBuchXgxriYpkOSqAR-ZMnjpXqK-9w@mail.gmail.com>

Yes, persistent commenting / threading somehow on some tool. And I trust
Herbert's judgement

On Saturday, May 7, 2016, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:

> The third one here. I think that process decisions can be made by chairman
> alone without calling votes, that's organizing part of job, not conceptual
> one.
>
> Vitaly
>
> On Sat, May 7, 2016 at 10:05 PM Richard Eisenberg <eir at cis.upenn.edu
> <javascript:_e(%7B%7D,'cvml','eir at cis.upenn.edu');>> wrote:
>
>> I second this motion to call a vote or other concrete, forward-moving
>> action on this topic.
>>
>> I, too, am refraining from commenting on other threads until this issue
>> is resolved.
>>
>> Richard
>>
>> On May 6, 2016, at 12:32 PM, M Farkas-Dyck <m.farkasdyck at gmail.com
>> <javascript:_e(%7B%7D,'cvml','m.farkasdyck at gmail.com');>> wrote:
>>
>> > I think we ought to make a choice quite soon. Proposals are already
>> > being made on this list, but i hesitate to make comment lest it be
>> > forgotten when we move to our new medium.
>> >
>> > My opinion on our choice of medium is known, i believe. Who or what
>> > makes the final call? hvr? committee member votes?
>> > _______________________________________________
>> > Haskell-prime mailing list
>> > Haskell-prime at haskell.org
>> <javascript:_e(%7B%7D,'cvml','Haskell-prime at haskell.org');>
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org
>> <javascript:_e(%7B%7D,'cvml','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/20160507/f9f35a42/attachment.html>

From wren at community.haskell.org  Sun May  8 01:39:30 2016
From: wren at community.haskell.org (wren romano)
Date: Sat, 7 May 2016 21:39:30 -0400
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <CAML5wvsyye-xttoSXHXy4yFneVqF3MgHziogGA8jq5WwviDG3w@mail.gmail.com>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
 <CAL3m8eDAzRuSq8eZxj1px9LaVgcAmj2QtUajAY3OTq+oP3ugBQ@mail.gmail.com>
 <CAML5wvsyye-xttoSXHXy4yFneVqF3MgHziogGA8jq5WwviDG3w@mail.gmail.com>
Message-ID: <CABUjdS7nsY5g9kQ+AQMxRszubmtM10bePJSDLFJmeRLqV5mUJw@mail.gmail.com>

On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese
<dominique.devriese at cs.kuleuven.be> wrote:
> As an outsider, I would like to suggest thinking about MonoLocalBinds.  GHC
> has a rather convincing story (at least to me) that "(local) let should not
> be generalised" (since it becomes problematic in combination with several
> other language extensions) and the journal version of the OutsideIn(X) paper
> has empirical data that indicates it is not a big problem to remove.  If
> there is a concern about backwards compatibility, perhaps the committee
> could deprecate local let generalisation in Haskell2020 and remove it in a
> subsequent iteration of the report?


FWIW, I'm against MonoLocalBinds. I understand the rational given in
the paper, but I disagree with it. In my experience the medicine is
worse than the disease.

It used to be that where-clauses where a nice clean way of organizing
code, especially for things like the worker/wrapper transform; but
with MonoLocalBinds all the benefits of where-clauses are eliminated.
For every local binding I'm forced to provide a type signature
?because part of the whole *point* of factoring things out is that
you're going to use them repeatedly, which for GADTs virtually
guarantees the uses will be at different index types and therefore
will require universal quantification? and these requisite type
signatures almost entirely duplicate information provided by the
signature for the primary/top-level binding. Indeed, in almost every
situation I end up needing to manually provide type signatures which
are identical to what let-generalization would have inferred. This
repetition is not merely annoying, it actively harms legibility and
maintainability of code.

-- 
Live well,
~wren

From wren at community.haskell.org  Sun May  8 01:48:13 2016
From: wren at community.haskell.org (wren romano)
Date: Sat, 7 May 2016 21:48:13 -0400
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <87eg9imgl5.fsf@gmail.com>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
 <CAL3m8eDOhnzDDheZQTuyKLT8q_8P3zt1baBkFc1xeDfZG4EncA@mail.gmail.com>
 <CALjd_v71+8JPsH1ExLknZh22SDG1yr-UaSNfO-GrnvUYZ0pBBQ@mail.gmail.com>
 <CABUjdS666Sm2XBF_tVL9dr2JNw3e_1OKROMnVt83kqUoAXVA6Q@mail.gmail.com>
 <87eg9imgl5.fsf@gmail.com>
Message-ID: <CABUjdS7dbCKB_9eTiXW922h5Obw_Tf4i6JDu6DPHq4xBOpdeCA@mail.gmail.com>

On Wed, May 4, 2016 at 3:23 AM, Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:
> On 2016-05-04 at 06:48:38 +0200, wren romano wrote:
>> Speaking of which, are things like the AMP and FTP under our purview
>> or are they under the CLC?
>
> I tried to clarify in the call-for-nomination and the formation
> announcement that the library part of the Haskell Report shall be
> formally under the CL(i)C's purview

I get that. My question was more because of how various things in the
Prelude are hard-coded into the rest of the report? in particular, the
core type classes feel like they span the boundary: the Monad class is
needed for the IO type for `main`, the fromInteger method of Num and
fromRational method of Fractional are needed for handling of numeric
literals, etc.

-- 
Live well,
~wren

From wren at community.haskell.org  Sun May  8 02:30:00 2016
From: wren at community.haskell.org (wren romano)
Date: Sat, 7 May 2016 22:30:00 -0400
Subject: The GADT debate
Message-ID: <CABUjdS77u0A52yQ865CW+5LwsePUyNyaE3MT1kEsJkVCa+CUfg@mail.gmail.com>

Hi all,

There's been some discussion about whether to consider including GADTs
in the new report, but it's been mixed up with other stuff in the
thread on incorporating extensions wholesale, which has unfortunately
preempted/preceded the discussion about how to go about having such
discussions(!).

My position on the debate is that we should avoid having the debate,
just yet. (Which I intended but failed to get across in the email
which unintentionally started this all off.) I think we have many much
lower-hanging fruit and it'd be a better use of our time to try and
get those squared away first. Doing so will help us figure out and
debug the process for having such debates, which should help the GADT
debate itself actually be fruitful. As well as making progress on
other fronts, so we don't get mired down first thing.

Whenever the debate occurs, here's a summary of the relevant emails so
that they are not lost, buried in the emails of time:


* Andres L?h puts forth criteria on how to judge whether extensions
should be included. Mentions GADTs as an example of something that, if
we decide they're a good idea in principle (criterion #1), then we
should work towards things which will help them be easier to
feasibly/sensibly specify (criterion #2)

    https://mail.haskell.org/pipermail/haskell-prime/2016-May/004104.html

* wren agrees with the criteria, loves GADTs, thinks they do not fully
satisfy criterion #2

    https://mail.haskell.org/pipermail/haskell-prime/2016-May/004115.html

* Simon Peyton Jones says type inference for GADTs has, in fact,
stabilized. Albeit, not entirely satisfactory because it's "a bit
operational"

    https://mail.haskell.org/pipermail/haskell-prime/2016-May/004119.html

* Henrik Nilsson thinks GADTs are one of the most important extensions
to Haskell (fwiw, wren agrees). Also worries about being able to
specify type inference declaratively.

    https://mail.haskell.org/pipermail/haskell-prime/2016-May/004120.html

* Dominique Devriese suggests including MonoLocalBinds, finds "let
should not be generalized" convincing

    https://mail.haskell.org/pipermail/haskell-prime/2016-May/004117.html

* wren finds "let should not be generalized" unconvincing

    https://mail.haskell.org/pipermail/haskell-prime/2016-May/004145.html

-- 
Live well,
~wren

From wren at community.haskell.org  Sun May  8 03:03:28 2016
From: wren at community.haskell.org (wren romano)
Date: Sat, 7 May 2016 23:03:28 -0400
Subject: Limber separators
In-Reply-To: <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
Message-ID: <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>

On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard <cgibbard at gmail.com> wrote:
> I can't really be the only one here who thinks that this kind of
> discussion of extensions to the syntax of Haskell is totally
> inappropriate when we have a large number of already implemented
> extensions to the language whose interactions with each other are
> largely undocumented. The Haskell Report isn't the place to be talking
> about new features, in my mind. If this project turns into
> bike-shedding the concrete syntax of the language, it's hard to
> imagine real progress being made on the actual problem, which is that
> the Haskell Reports as they stand are not as relevant as they should
> be with regard to the language in which we're writing programs today.


+1.

One of my big concerns here is that the proposal is vague, and
therefore impossible to judge. As an example of what I mean, what
counts as a "separator"? Is it a special case only commas? Why not
also include the vertical pipe in data type definitions? We run into
the same "difficult to one-line merge" issues when we write things
like:

    data SomeReallyLongNameSoIWantToNewlineWrap
        = Foo ...
        | Bar ...
        ...

Coq and other ML-like languages allow a vertical pipe between the "="
and the first constructor name, so why shouldn't we? Or, what about
when people do parser combinator stuff and use the (<|>) operator as a
"separator", should we handle that too? If so, do we extend it to
other operators people may want as a leading separator, like (+) in
large arithmetic expressions? How should these be distinguished from
typos where an argument is missing or a section was indented?


These sorts of complexities are the reason the Haskell' committee has
always focused on things which have already been implemented. The
implementation provides (a) a concrete specification of what's being
proposed, (b) an idea of how that proposal works in the wild, (c) a
proof that it's easily implementable. Of course, in the process of
getting included into the report the details may change; but it's a
very solid starting point. I'm not adamantly opposed to proposals
which aren't already implemented, but the proposal should measure up
to the same standards? N.B., it may appear to be held to higher
standards, since people often neglect to consider the role an
implementation plays as a component of the proposal itself.

As you say, four years is a decent chunk of time. Why not spend that
time getting it implemented as an extension in GHC? The implementation
process will work out a bunch of kinks in what exactly you mean by
"separators" and how to handle leading vs trailing vs redundant
separators. Having it available will also make it clearer how many
people like and want this behavior. Both of these contribute to making
the argument that we should in fact include it in the report.

-- 
Live well,
~wren

From gershomb at gmail.com  Sun May  8 03:05:23 2016
From: gershomb at gmail.com (Gershom B)
Date: Sat, 7 May 2016 23:05:23 -0400
Subject: The GADT debate
In-Reply-To: <CABUjdS77u0A52yQ865CW+5LwsePUyNyaE3MT1kEsJkVCa+CUfg@mail.gmail.com>
References: <CABUjdS77u0A52yQ865CW+5LwsePUyNyaE3MT1kEsJkVCa+CUfg@mail.gmail.com>
Message-ID: <etPan.572ead30.317d6929.113@mbp.local>

On May 7, 2016 at 10:30:05 PM, wren romano (wren at community.haskell.org) wrote:
> Hi all,
>  
> There's been some discussion about whether to consider including GADTs
> in the new report, but it's been mixed up with other stuff in the
> thread on incorporating extensions wholesale, which has unfortunately
> preempted/preceded the discussion about how to go about having such
> discussions(!).
>  
> My position on the debate is that we should avoid having the debate,
> just yet. (Which I intended but failed to get across in the email
> which unintentionally started this all off.) I think we have many much
> lower-hanging fruit and it'd be a better use of our time to try and
> get those squared away first. Doing so will help us figure out and
> debug the process for having such debates, which should help the GADT
> debate itself actually be fruitful. As well as making progress on
> other fronts, so we don't get mired down first thing.

Thanks for this summary Wren. Let me add something I would be interested in seeing happen in the ?meantime? ? an attempt (orthogonal to the prime committee at first) to specify an algorithm for inference that is easier to describe and implement than OutsideIn, and which is strictly less powerful. (And indeed whose specification can be given in a page or two of the report). A compliant compiler could then be required to have inference ?at least? that good, but also be allowed to go ?above and beyond?. Thus fully portable H2020 code might require more specified signatures than we need in GHC proper, but all such code would also typecheck in GHC. It seems to me that the creation of such an algorithm might be an interesting bit of research in itself.

?Gershom

From carter.schonwald at gmail.com  Sun May  8 05:33:48 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 8 May 2016 01:33:48 -0400
Subject: Limber separators
In-Reply-To: <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
 <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
Message-ID: <CAHYVw0yPQByO_xnq5vZ0hMnBuhmoLuSuZRZHySpSDysV7nAiSQ@mail.gmail.com>

On Saturday, May 7, 2016, wren romano <wren at community.haskell.org> wrote:

> On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard <cgibbard at gmail.com
> <javascript:;>> wrote:
> > I can't really be the only one here who thinks that this kind of
> > discussion of extensions to the syntax of Haskell is totally
> > inappropriate when we have a large number of already implemented
> > extensions to the language whose interactions with each other are
> > largely undocumented. The Haskell Report isn't the place to be talking
> > about new features, in my mind. If this project turns into
> > bike-shedding the concrete syntax of the language, it's hard to
> > imagine real progress being made on the actual problem, which is that
> > the Haskell Reports as they stand are not as relevant as they should
> > be with regard to the language in which we're writing programs today.
>
>
> +1.
>
> One of my big concerns here is that the proposal is vague, and
> therefore impossible to judge. As an example of what I mean, what
> counts as a "separator"? Is it a special case only commas? Why not
> also include the vertical pipe in data type definitions? We run into
> the same "difficult to one-line merge" issues when we write things
> like:
>
>     data SomeReallyLongNameSoIWantToNewlineWrap
>         = Foo ...
>         | Bar ...
>         ...
>
> Coq and other ML-like languages allow a vertical pipe between the "="
> and the first constructor name, so why shouldn't we? Or, what about
> when people do parser combinator stuff and use the (<|>) operator as a
> "separator", should we handle that too? If so, do we extend it to
> other operators people may want as a leading separator, like (+) in
> large arithmetic expressions? How should these be distinguished from
> typos where an argument is missing or a section was indented?
>
>
> These sorts of complexities are the reason the Haskell' committee has
> always focused on things which have already been implemented. The
> implementation provides (a) a concrete specification of what's being
> proposed, (b) an idea of how that proposal works in the wild, (c) a
> proof that it's easily implementable. Of course, in the process of
> getting included into the report the details may change; but it's a
> very solid starting point. I'm not adamantly opposed to proposals
> which aren't already implemented, but the proposal should measure up
> to the same standards? N.B., it may appear to be held to higher
> standards, since people often neglect to consider the role an
> implementation plays as a component of the proposal itself.
>
> As you say, four years is a decent chunk of time. Why not spend that
> time getting it implemented as an extension in GHC? The implementation
> process will work out a bunch of kinks in what exactly you mean by
> "separators" and how to handle leading vs trailing vs redundant
> separators. Having it available will also make it clearer how many
> people like and want this behavior. Both of these contribute to making
> the argument that we should in fact include it in the report.
>
> --
> Live well,
> ~wren
> ______________________________


>
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160508/66effd39/attachment.html>

From carter.schonwald at gmail.com  Sun May  8 05:38:46 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 8 May 2016 01:38:46 -0400
Subject: The GADT debate
In-Reply-To: <etPan.572ead30.317d6929.113@mbp.local>
References: <CABUjdS77u0A52yQ865CW+5LwsePUyNyaE3MT1kEsJkVCa+CUfg@mail.gmail.com>
 <etPan.572ead30.317d6929.113@mbp.local>
Message-ID: <CAHYVw0wVMPpw0fE_=RUVLu+W-4HxyWiXN3TOH4VL21n8KmbZFg@mail.gmail.com>

On Saturday, May 7, 2016, Gershom B <gershomb at gmail.com> wrote:

> On May 7, 2016 at 10:30:05 PM, wren romano (wren at community.haskell.org
> <javascript:;>) wrote:
> > Hi all,
> >
> > There's been some discussion about whether to consider including GADTs
> > in the new report, but it's been mixed up with other stuff in the
> > thread on incorporating extensions wholesale, which has unfortunately
> > preempted/preceded the discussion about how to go about having such
> > discussions(!).
> >
> > My position on the debate is that we should avoid having the debate,
> > just yet. (Which I intended but failed to get across in the email
> > which unintentionally started this all off.) I think we have many much
> > lower-hanging fruit and it'd be a better use of our time to try and
> > get those squared away first. Doing so will help us figure out and
> > debug the process for having such debates, which should help the GADT
> > debate itself actually be fruitful. As well as making progress on
> > other fronts, so we don't get mired down first thing.
>
> Thanks for this summary Wren. Let me add something I would be interested
> in seeing happen in the ?meantime? ? an attempt (orthogonal to the prime
> committee at first) to specify an algorithm for inference that is easier to
> describe and implement than OutsideIn, and which is strictly less powerful.
> (And indeed whose specification can be given in a page or two of the
> report). A compliant compiler could then be required to have inference ?at
> least? that good, but also be allowed to go ?above and beyond?. Thus fully
> portable H2020 code might require more specified signatures than we need in
> GHC proper, but all such code would also typecheck in GHC. It seems to me
> that the creation of such an algorithm might be an interesting bit of
> research in itself.
>
> ?Gershom


I agree, there's definitely value in some research / engineering work that
articulates a clear simple checker and a simple and slightly conservative
inference alg , and that could pave a nice path towards gadts inclusion or
at least a concrete starting point. Thanks for articulating this, I've been
thinking much the same thing.  Of course the proof is in the pudding for
how it works out :)


Peripherally, this also brings up the notion of type equality, and I'm a
bit fuzzy about how big a chasm there is between what that means in Haskell
2010 vs more bleeding edge styles, or am I pointing at a shadows?



> _______________________________________________
> 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/20160508/60b3d5ca/attachment.html>

From alexander at plaimi.net  Sun May  8 10:27:07 2016
From: alexander at plaimi.net (Alexander Berntsen)
Date: Sun, 8 May 2016 12:27:07 +0200
Subject: Limber separators
In-Reply-To: <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
 <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
Message-ID: <572F147B.7010300@plaimi.net>

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

On 08/05/16 05:03, wren romano wrote:
> One of my big concerns here is that the proposal is vague, and 
> therefore impossible to judge.
It is intentionally somewhat vague because I would the committee to
address this problem which is largely solved in many other languages,
but remains a -- to many bizarre -- problem in Haskell

> As an example of what I mean, what counts as a "separator"? Is it
> a special case only commas? Why not also include the vertical pipe
> in data type definitions?
If you read my email, you will see that I *am* including them.

> Coq and other ML-like languages allow a vertical pipe between the 
> "=" and the first constructor name, so why shouldn't we? Or, what 
> about when people do parser combinator stuff and use the (<|>) 
> operator as a "separator", should we handle that too?
That's function (operator) application. I would think that it was
entirely obvious that I did not mean that users should be able to
write 'f f f f f f f x x x x x x x x' and have the compiler work out
that the user meant 'f x'. If it wasn't, then I'm saying it now. I did
not mean to include operators or function application. I'm not sure
how that could even make sense.

I am slightly bemused by the amount of complexity this list is
imposing on a -- to me -- relatively straightforward idea.


I realise now that the report is not the place to fix problems with
Haskell, but to standardise solutions that a high enough percentage of
packages already rely on. I misjudged the ambition level of the
report. Thus I withdraw this proposal to not waste the committees time
any further.

Please note that I don't mean this email to be a critique of the scope
or ambition of the report -- I think that standardising solutions
should be the clearly most important goal of this committee.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXLxR6AAoJENQqWdRUGk8BtlYP/RBm8cMLm3HzJA6fPnRHhhbj
tomHfLqgg/2ZDs05wHY4v0rI5KMmQzfsZIJAJbv8FiWUprkW3X6YaKetxyICIfh/
KmBsqppACDEi62OEB28QAgvRmKy5zrsJOiT2a8Dg2IHUqfHvfAtk11sC1kscWXNa
cjtfn0etNvOfLEJLU1pjUXf5iTLrkR0JQSAUsGn3vXhneWeMx2SkanH2H5PUXv1c
hVIbUWXGC5M/VU9fp5O1xckHHboSPRJlSQbMx8srtN+3A65UdRZfCoH2HQ34+Tc3
j1kVKV9zF6X0GAogq3gdzqicCgMgfA46P7z3YdneTov78N8XfeD5CGJQrns+/iCF
kube5pYhjHRws89rHJQjSsH/Jqz4+CPFbkyhyCs/ZorRrPlsFhz5Vtu5oeQN3nqZ
PyntRUyQUpAYMJuwwGs8x1rxGScq/s+/6PvduznnYKwJFtaz0WQStLUK9zNQFwxN
xXcQ6pFkeFqXM1ideHpCpP0bg25LQZps4WkAk7sGEgl1SkTQkS+a1m0DDZbE85HN
P2Jz+XORwd+Y+n7KBmZbxPQDgmH8z/6d23F1UPEBwTG3A3GFSVw+Devwf1eZrv1G
p+SNbVQVQlLvMF4gfQmfkYUSBk8muOtJPcXvAXOeuLTsI/WfI2jHhndizT4tYFsm
mavFWSy2Fg89K1d+w4c9
=3/+J
-----END PGP SIGNATURE-----

From eir at cis.upenn.edu  Sun May  8 15:25:21 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 8 May 2016 11:25:21 -0400
Subject: The GADT debate
In-Reply-To: <etPan.572ead30.317d6929.113@mbp.local>
References: <CABUjdS77u0A52yQ865CW+5LwsePUyNyaE3MT1kEsJkVCa+CUfg@mail.gmail.com>
 <etPan.572ead30.317d6929.113@mbp.local>
Message-ID: <4CFB6917-1523-4430-9810-A2DDC2360229@cis.upenn.edu>


On May 7, 2016, at 11:05 PM, Gershom B <gershomb at gmail.com> wrote:
> 
> an attempt (orthogonal to the prime committee at first) to specify an algorithm for inference that is easier to describe and implement than OutsideIn, and which is strictly less powerful. (And indeed whose specification can be given in a page or two of the report).

Stephanie Weirich and I indeed considered doing such a thing, which conversation was inspired by my joining the Haskell Prime committee. We concluded that this would indeed be a research question that is, as yet, unanswered in the literature. The best we could come up with based on current knowledge would be to require type signatures on:

1. The scrutinee
2. Every case branch
3. The case as a whole

With all of these type signatures in place, GADT type inference is indeed straightforward. As a strawman, I would be open to standardizing GADTs with these requirements in place and the caveat that implementations are welcome to require fewer signatures. Even better would be to do this research and come up with a good answer. I may very well be open to doing such a research project, but not for at least a year. (My research agenda for the next year seems fairly solid at this point.) If someone else wants to spearhead and wants advice / a sounding board / a less active co-author, I may be willing to join.

Richard

From carter.schonwald at gmail.com  Sun May  8 15:36:38 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 8 May 2016 11:36:38 -0400
Subject: The GADT debate
In-Reply-To: <4CFB6917-1523-4430-9810-A2DDC2360229@cis.upenn.edu>
References: <CABUjdS77u0A52yQ865CW+5LwsePUyNyaE3MT1kEsJkVCa+CUfg@mail.gmail.com>
 <etPan.572ead30.317d6929.113@mbp.local>
 <4CFB6917-1523-4430-9810-A2DDC2360229@cis.upenn.edu>
Message-ID: <CAHYVw0zjfLZtaLvAWkve33jjBn8r8Aw3KvADHWwBjcpxm7cGVw@mail.gmail.com>

On Sunday, May 8, 2016, Richard Eisenberg <eir at cis.upenn.edu> wrote:

>
> On May 7, 2016, at 11:05 PM, Gershom B <gershomb at gmail.com <javascript:;>>
> wrote:
> >
> > an attempt (orthogonal to the prime committee at first) to specify an
> algorithm for inference that is easier to describe and implement than
> OutsideIn, and which is strictly less powerful. (And indeed whose
> specification can be given in a page or two of the report).
>
> Stephanie Weirich and I indeed considered doing such a thing, which
> conversation was inspired by my joining the Haskell Prime committee. We
> concluded that this would indeed be a research question that is, as yet,
> unanswered in the literature. The best we could come up with based on
> current knowledge would be to require type signatures on:
>
> 1. The scrutinee
> 2. Every case branch
> 3. The case as a whole
>
> With all of these type signatures in place, GADT type inference is indeed
> straightforward. As a strawman, I would be open to standardizing GADTs with
> these requirements in place and the caveat that implementations are welcome
> to require fewer signatures. Even better would be to do this research and
> come up with a good answer. I may very well be open to doing such a
> research project, but not for at least a year. (My research agenda for the
> next year seems fairly solid at this point.) If someone else wants to
> spearhead and wants advice / a sounding board / a less active co-author, I
> may be willing to join.
>
> Richard



This sounds awesome.  One question I'm wondering about is what parts of the
type inference problem aren't part of the same challenge in equivalent
dependent data types? I've been doing some Intersting stuff on the latter
front recently.

It seems that those two are closely related, but I guess there might be
some complications in Haskell semantics for thst? And or is this alluded to
in existing work on gadts?



> _______________________________________________
> 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/20160508/a30935fd/attachment.html>

From iavor.diatchki at gmail.com  Sun May  8 20:54:14 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun, 8 May 2016 13:54:14 -0700
Subject: The GADT debate
In-Reply-To: <CAHYVw0zjfLZtaLvAWkve33jjBn8r8Aw3KvADHWwBjcpxm7cGVw@mail.gmail.com>
References: <CABUjdS77u0A52yQ865CW+5LwsePUyNyaE3MT1kEsJkVCa+CUfg@mail.gmail.com>
 <etPan.572ead30.317d6929.113@mbp.local>
 <4CFB6917-1523-4430-9810-A2DDC2360229@cis.upenn.edu>
 <CAHYVw0zjfLZtaLvAWkve33jjBn8r8Aw3KvADHWwBjcpxm7cGVw@mail.gmail.com>
Message-ID: <CAGK9nuqCuqKUrvQtQsYyofP1Kx55gJPuSoWcRoE31C5uYbNRBw@mail.gmail.com>

Hello,

what is the state with the semantic specification of GADTs?  I am wondering
if they fit in the usual CPO-style semantics for Haskell, or do we need
some more exotic mathematical structure to give semantics to the language.

-Iavor




On Sun, May 8, 2016 at 8:36 AM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

>
>
> On Sunday, May 8, 2016, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>
>>
>> On May 7, 2016, at 11:05 PM, Gershom B <gershomb at gmail.com> wrote:
>> >
>> > an attempt (orthogonal to the prime committee at first) to specify an
>> algorithm for inference that is easier to describe and implement than
>> OutsideIn, and which is strictly less powerful. (And indeed whose
>> specification can be given in a page or two of the report).
>>
>> Stephanie Weirich and I indeed considered doing such a thing, which
>> conversation was inspired by my joining the Haskell Prime committee. We
>> concluded that this would indeed be a research question that is, as yet,
>> unanswered in the literature. The best we could come up with based on
>> current knowledge would be to require type signatures on:
>>
>> 1. The scrutinee
>> 2. Every case branch
>> 3. The case as a whole
>>
>> With all of these type signatures in place, GADT type inference is indeed
>> straightforward. As a strawman, I would be open to standardizing GADTs with
>> these requirements in place and the caveat that implementations are welcome
>> to require fewer signatures. Even better would be to do this research and
>> come up with a good answer. I may very well be open to doing such a
>> research project, but not for at least a year. (My research agenda for the
>> next year seems fairly solid at this point.) If someone else wants to
>> spearhead and wants advice / a sounding board / a less active co-author, I
>> may be willing to join.
>>
>> Richard
>
>
>
> This sounds awesome.  One question I'm wondering about is what parts of
> the type inference problem aren't part of the same challenge in equivalent
> dependent data types? I've been doing some Intersting stuff on the latter
> front recently.
>
> It seems that those two are closely related, but I guess there might be
> some complications in Haskell semantics for thst? And or is this alluded to
> in existing work on gadts?
>
>
>
>> _______________________________________________
>> 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/20160508/cb500ee0/attachment.html>

From wren at community.haskell.org  Mon May  9 00:40:02 2016
From: wren at community.haskell.org (wren romano)
Date: Sun, 8 May 2016 20:40:02 -0400
Subject: The GADT debate
In-Reply-To: <4CFB6917-1523-4430-9810-A2DDC2360229@cis.upenn.edu>
References: <CABUjdS77u0A52yQ865CW+5LwsePUyNyaE3MT1kEsJkVCa+CUfg@mail.gmail.com>
 <etPan.572ead30.317d6929.113@mbp.local>
 <4CFB6917-1523-4430-9810-A2DDC2360229@cis.upenn.edu>
Message-ID: <CABUjdS7x_2WuGR+VhQvc5RuYk=7tATBg6o_-bO2VtqwvWZwSAQ@mail.gmail.com>

On Sun, May 8, 2016 at 11:25 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> On May 7, 2016, at 11:05 PM, Gershom B <gershomb at gmail.com> wrote:
>>
>> an attempt (orthogonal to the prime committee at first) to specify an algorithm for inference that is easier to describe and implement than OutsideIn, and which is strictly less powerful. (And indeed whose specification can be given in a page or two of the report).
>
> Stephanie Weirich and I indeed considered doing such a thing, which conversation was inspired by my joining the Haskell Prime committee. We concluded that this would indeed be a research question that is, as yet, unanswered in the literature. The best we could come up with based on current knowledge would be to require type signatures on:
>
> 1. The scrutinee
> 2. Every case branch
> 3. The case as a whole
>
> With all of these type signatures in place, GADT type inference is indeed straightforward.

If all three of those signatures are present, doesn't that make
"inference" trivial? If I understand you correctly, the only thing to
do here would be to check the types, right?

I am curious though. Since we don't have true/anonymous type-level
functions, why do we need the signatures on every branch (assuming the
scrutinee and whole-expression types are given)? I can see why they'd
be required in Coq/Agda/etc, but it's less clear why they'd be
required in Haskell per se

-- 
Live well,
~wren

From wren at community.haskell.org  Mon May  9 01:17:58 2016
From: wren at community.haskell.org (wren romano)
Date: Sun, 8 May 2016 21:17:58 -0400
Subject: The GADT debate
In-Reply-To: <CAHYVw0wVMPpw0fE_=RUVLu+W-4HxyWiXN3TOH4VL21n8KmbZFg@mail.gmail.com>
References: <CABUjdS77u0A52yQ865CW+5LwsePUyNyaE3MT1kEsJkVCa+CUfg@mail.gmail.com>
 <etPan.572ead30.317d6929.113@mbp.local>
 <CAHYVw0wVMPpw0fE_=RUVLu+W-4HxyWiXN3TOH4VL21n8KmbZFg@mail.gmail.com>
Message-ID: <CABUjdS4=EmeKPjjs+pKn2TfoELggzBYWF+MDH4GcT=hLMpRF2w@mail.gmail.com>

On Sun, May 8, 2016 at 1:38 AM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> Peripherally, this also brings up the notion of type equality, and I'm a bit
> fuzzy about how big a chasm there is between what that means in Haskell 2010
> vs more bleeding edge styles, or am I pointing at a shadows?

Generally speaking, notions of "equality" are a major source of
complication in any dependently typed theory. The issue isn't coming
up with a story that works, but rather choosing between a number of
different stories each of which works in slightly different ways. This
problem of "equality" is the bulk of why I think it'd be good to
postpone the GADT (and TypeFamily) debate.

One Haskell-specific example of why defining equality is hard is when
we try to handle both the "equalities" induced by dependent
case-analysis as well as the "equalities" induced by newtype
definitions. Though we use the same word for them, they're two
entirely different notions of "equality". However, since they both
exist, we must have some story for how these two notions interact with
one another (including possibly "not at all"). The new role-typing
stuff is one approach to handling this, but many people feel it's
overly complicated or otherwise not quite the right way forward. If we
add GADTs to the report, then we also need to define how to type check
dependent case-analysis, which seems to require introducing type
equality, which in turn requires specifying how the semantic notion of
type equality interacts with the operational notion of representation
equality introduced by newtypes, which is still imo an open area of
research.

If we can come up with some story that lets us make progress towards
eventually including GADTs (and TypeFamilies) while avoiding the
equality tarpit, I'm all for it. I'd just really rather avoid the
tarpit until we have other easier things squared away.

...

One possible way forward may be to introduce the syntax for (~)
constraints and defining them merely as "delayed unification
constraints". This would require including unification in the report,
but may be doable in a way that allows non-unification-based
implementations as well.

The reason I bring this possibility up now is that it helps handle
some other situations where we don't even have GADTs or TypeFamilies.
In particular, when FlexibleInstances is enabled it allows for
non-linear use of type variables in the instance head. However, this
is often not what we mean since "instance Foo (Bar i i)" means that
the two parameters to Bar must be unified *prior* to selecting that
instance; which often leads to type inference issues since we can't
resolve the instance eagerly enough. Whereas, often times what is
actually desired is "instance (i ~ j) => Foo (Bar i j)" which causes
us to select the instance immediately if the type constructor is Bar,
and then *after* committing to the instance we then try to unify the
two parameters. Thus, adding delayed unification constraints would be
helpful for adding (something like) FlexibleInstances to the report.
Of course, "delayed unification constraints" don't have any sort of
evidence associated with them like the dependent case-analysis
equalities do; so, again, we'd want to make sure to phrase things in
such a way that we don't prematurely commit to more than we intend.

-- 
Live well,
~wren

From eir at cis.upenn.edu  Mon May  9 01:25:23 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 8 May 2016 21:25:23 -0400
Subject: Scope of committee (can we do *new* things?)
In-Reply-To: <572F147B.7010300@plaimi.net>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
 <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
 <572F147B.7010300@plaimi.net>
Message-ID: <3016DD2F-1BEC-4912-B686-05CE4872AFA2@cis.upenn.edu>


On May 8, 2016, at 6:27 AM, Alexander Berntsen <alexander at plaimi.net> wrote:
> 
> I realise now that the report is not the place to fix problems with
> Haskell, but to standardise solutions that a high enough percentage of
> packages already rely on. I misjudged the ambition level of the
> report. Thus I withdraw this proposal to not waste the committees time
> any further.

The above snippet has been taken from the "Limber separators" thread. I don't wish to debate limber separators at the moment, but I think Alexander raises a good question here: 

Should we endeavor to take on any as-yet-unimplemented behavior that might make Haskell better?

My own opinion is a resounding "yes!"

If we say "no", we're left with a terrible chicken-and-egg problem. I have seen some proposed extensions to GHC be thrown out because they would fragment the language unnecessarily. Chief in my head is that proposal to allow `case`, `if`, `do`, etc., in a function application without parentheses or a $ operator. That is, to permit `runST do blah; blah`. (See https://ghc.haskell.org/trac/ghc/ticket/10843) A common rebuttal against this proposal was that implementing the extension would involve a lot of huffing and puffing over a few characters, and that now all Haskell readers may have to be aware of this new extension, even if an individual doesn't write with it. However, the Haskell Prime committee is a great place to debate such a change. If we move quickly, we can even implement it, get it into GHC (or some other Haskell compiler, I suppose), and get feedback before we set the standard in stone.

I do absolutely think we should be cautious about addressing unimplemented behavior. I would be strongly against a new type-system extension that hasn't been field-tested. However, I do think pondering lexical/parsical changes (such as limber separators) should be considered in scope.

Richard

From gershomb at gmail.com  Mon May  9 03:26:51 2016
From: gershomb at gmail.com (Gershom B)
Date: Sun, 8 May 2016 23:26:51 -0400
Subject: Scope of committee (can we do *new* things?)
In-Reply-To: <3016DD2F-1BEC-4912-B686-05CE4872AFA2@cis.upenn.edu>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
 <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
 <572F147B.7010300@plaimi.net>
 <3016DD2F-1BEC-4912-B686-05CE4872AFA2@cis.upenn.edu>
Message-ID: <etPan.573003b7.1cde5c44.113@mbp.local>

On May 8, 2016 at 9:25:33 PM, Richard Eisenberg (eir at cis.upenn.edu) wrote:
>  
> I do absolutely think we should be cautious about addressing unimplemented behavior.  
> I would be strongly against a new type-system extension that hasn't been field-tested.  
> However, I do think pondering lexical/parsical changes (such as limber separators)  
> should be considered in scope.

While such changes should definitely be in scope, I do think that the proper mechanism would be to garner enough interest to get a patch into GHC (whether through discussion on the -prime list or elsewhere) and have an experimental implementation, even for syntax changes, before such proposals are considered ready for acceptance into a standard as such. But I also agree that discussion of things which may be in the pre-implementation phase are in scope ? just that the next step is to get them past that phase before they?re considered for inclusion as such. There are enough traps in parsing that specification without an implementation is always a risky choice. ?Recall for example the case of fixity resolution, finally fixed in Haskell2010 (https://prime.haskell.org/wiki/FixityResolution) where the behavior in the report was at variance with all implementations.

I would hope that if a segment of the prime committee wants to test-run an experimental syntax feature, then this would take sufficient precedence over concerns regarding ?language fragmentation? that the GHC team would be open to guarding it behind a flag. Given the number of GHC developers involved in this effort, I think that?s not a bad estimation :-)

Cheers,
Gershom

From simonpj at microsoft.com  Mon May  9 08:18:24 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 9 May 2016 08:18:24 +0000
Subject: Are there GHC extensions we'd like to incorporate wholesale?
In-Reply-To: <CABUjdS7nsY5g9kQ+AQMxRszubmtM10bePJSDLFJmeRLqV5mUJw@mail.gmail.com>
References: <m2bn4orrtp.fsf@newartisans.com>
 <etPan.57281ebf.2e6841da.113@mbp.local>
 <CAF3RzK_U22xfFycVrXUb0zmMYuU2D8zyNJvdXXBSej+jerCsQQ@mail.gmail.com>
 <CAL3m8eDAzRuSq8eZxj1px9LaVgcAmj2QtUajAY3OTq+oP3ugBQ@mail.gmail.com>
 <CAML5wvsyye-xttoSXHXy4yFneVqF3MgHziogGA8jq5WwviDG3w@mail.gmail.com>
 <CABUjdS7nsY5g9kQ+AQMxRszubmtM10bePJSDLFJmeRLqV5mUJw@mail.gmail.com>
Message-ID: <78f9e3fbe14a4f7d918ea363528e8386@DB4PR30MB030.064d.mgd.msft.net>

Just to be clear, MonoLocalBinds, as implemented, does not apply to local bindings that could equally well have been written at top level; that is, they do not mention any locally-bound variables (except other local bindings that could themselves be floated).

So you are at liberty to use where for stylistic reasons.

You may still dislike the cure, but the disease is pretty bad.  Do suggest alternative cures!

This is not to argue for or against MonoLocalBinds for Haskell Prime.

Simon

|  -----Original Message-----
|  From: Haskell-prime [mailto:haskell-prime-bounces at haskell.org] On
|  Behalf Of wren romano
|  Sent: 08 May 2016 02:40
|  To: haskell-prime at haskell.org List <Haskell-prime at haskell.org>
|  Subject: Re: Are there GHC extensions we'd like to incorporate
|  wholesale?
|  
|  On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese
|  <dominique.devriese at cs.kuleuven.be> wrote:
|  > As an outsider, I would like to suggest thinking about
|  MonoLocalBinds.
|  > GHC has a rather convincing story (at least to me) that "(local) let
|  > should not be generalised" (since it becomes problematic in
|  > combination with several other language extensions) and the journal
|  > version of the OutsideIn(X) paper has empirical data that indicates
|  it
|  > is not a big problem to remove.  If there is a concern about
|  backwards
|  > compatibility, perhaps the committee could deprecate local let
|  > generalisation in Haskell2020 and remove it in a subsequent iteration
|  of the report?
|  
|  
|  FWIW, I'm against MonoLocalBinds. I understand the rational given in
|  the paper, but I disagree with it. In my experience the medicine is
|  worse than the disease.
|  
|  It used to be that where-clauses where a nice clean way of organizing
|  code, especially for things like the worker/wrapper transform; but with
|  MonoLocalBinds all the benefits of where-clauses are eliminated.
|  For every local binding I'm forced to provide a type signature ?because
|  part of the whole *point* of factoring things out is that you're going
|  to use them repeatedly, which for GADTs virtually guarantees the uses
|  will be at different index types and therefore will require universal
|  quantification? and these requisite type signatures almost entirely
|  duplicate information provided by the signature for the primary/top-
|  level binding. Indeed, in almost every situation I end up needing to
|  manually provide type signatures which are identical to what let-
|  generalization would have inferred. This repetition is not merely
|  annoying, it actively harms legibility and maintainability of code.
|  
|  --
|  Live well,
|  ~wren
|  _______________________________________________
|  Haskell-prime mailing list
|  Haskell-prime at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fhaskell-
|  prime&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd15df870d2b4441
|  c57c808d376e19b35%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U2WAdUt4
|  qXclT7F7G93J1zVylYv3CvhqNuNHeem%2fvEg%3d

From Lennart.Augustsson at sc.com  Mon May  9 08:27:26 2016
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Mon, 9 May 2016 08:27:26 +0000
Subject: The GADT debate
In-Reply-To: <4CFB6917-1523-4430-9810-A2DDC2360229@cis.upenn.edu>
References: <CABUjdS77u0A52yQ865CW+5LwsePUyNyaE3MT1kEsJkVCa+CUfg@mail.gmail.com>
 <etPan.572ead30.317d6929.113@mbp.local>
 <4CFB6917-1523-4430-9810-A2DDC2360229@cis.upenn.edu>
Message-ID: <22B950C955F8AB4196E72698FBD00002D0326BAD@UKWPISXMB01B.zone1.scb.net>

Do you really need that many type signatures?  I remember trying to work out what extra information is needed when type checking case with dependent types.  If memory serves, you can get by with just specifying the single (type) function that is instantiated in each arm and in the conclusion.  Maybe something similar is possible here.

       

-----Original Message-----
From: Haskell-prime [mailto:haskell-prime-bounces at haskell.org] On Behalf Of Richard Eisenberg
Sent: 08 May 2016 16:25
To: Gershom B
Cc: haskell-prime at haskell.org List
Subject: Re: The GADT debate


On May 7, 2016, at 11:05 PM, Gershom B <gershomb at gmail.com> wrote:
> 
> an attempt (orthogonal to the prime committee at first) to specify an algorithm for inference that is easier to describe and implement than OutsideIn, and which is strictly less powerful. (And indeed whose specification can be given in a page or two of the report).

Stephanie Weirich and I indeed considered doing such a thing, which conversation was inspired by my joining the Haskell Prime committee. We concluded that this would indeed be a research question that is, as yet, unanswered in the literature. The best we could come up with based on current knowledge would be to require type signatures on:

1. The scrutinee
2. Every case branch
3. The case as a whole

With all of these type signatures in place, GADT type inference is indeed straightforward. As a strawman, I would be open to standardizing GADTs with these requirements in place and the caveat that implementations are welcome to require fewer signatures. Even better would be to do this research and come up with a good answer. I may very well be open to doing such a research project, but not for at least a year. (My research agenda for the next year seems fairly solid at this point.) If someone else wants to spearhead and wants advice / a sounding board / a less active co-author, I may be willing to join.

Richard
_______________________________________________
Haskell-prime mailing list
Haskell-prime at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.

From hjgtuyl at chello.nl  Mon May  9 13:50:45 2016
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Mon, 09 May 2016 15:50:45 +0200
Subject: Infrastructure & Communication
In-Reply-To: <CAEs96n182H+j3Kzf4+E5m+w9V9oq0aywn564PeNbNxK_5d2wrQ@mail.gmail.com>
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>
 <CAEs96n182H+j3Kzf4+E5m+w9V9oq0aywn564PeNbNxK_5d2wrQ@mail.gmail.com>
Message-ID: <op.yg67ezolpz0j5l@alquantor>

On Sun, 01 May 2016 00:22:44 +0200, Austin Seipp <austin at well-typed.com>
wrote:
:
>   - 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.
:

Previous committees used a mailing list for this, the most recent one is:
             haskell-2011-committee at haskell.org

I am not saying we should repeat this, just mentioning the option.

Regards,
Henk-Jan van Tuyl


-- 
Folding at home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From hjgtuyl at chello.nl  Mon May  9 13:51:18 2016
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Mon, 09 May 2016 15:51:18 +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: <op.yg67fsghpz0j5l@alquantor>

On Sat, 30 Apr 2016 10:03:55 +0200, Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:

> Hello *,
:
> | 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.
:

I think it's great that you want to do this!

Regards,
Henk-Jan van Tuyl


-- 
Folding at home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From johnw at newartisans.com  Wed May 11 18:17:03 2016
From: johnw at newartisans.com (John Wiegley)
Date: Wed, 11 May 2016 11:17:03 -0700
Subject: Scope of committee (can we do *new* things?)
In-Reply-To: <etPan.573003b7.1cde5c44.113@mbp.local> (Gershom B.'s message of
 "Sun, 8 May 2016 23:26:51 -0400")
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
 <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
 <572F147B.7010300@plaimi.net>
 <3016DD2F-1BEC-4912-B686-05CE4872AFA2@cis.upenn.edu>
 <etPan.573003b7.1cde5c44.113@mbp.local>
Message-ID: <m2lh3g8nog.fsf@newartisans.com>

>>>>> Gershom B <gershomb at gmail.com> writes:

> While such changes should definitely be in scope, I do think that the proper
> mechanism would be to garner enough interest to get a patch into GHC
> (whether through discussion on the -prime list or elsewhere) and have an
> experimental implementation, even for syntax changes, before such proposals
> are considered ready for acceptance into a standard as such.

Just a side note: This is often how the C++ committee proceeds as well: a
language proposal with an experimental implementation is given much higher
credence than paperware. However, they don't exclude paperware either.

So I don't think we need to rely on implementation before considering a
feature we all want, but I do agree that seeing a patch in GHC first allows
for much testing and experimentation.

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

From iavor.diatchki at gmail.com  Thu May 12 19:46:17 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 12 May 2016 12:46:17 -0700
Subject: Scope of committee (can we do *new* things?)
In-Reply-To: <m2lh3g8nog.fsf@newartisans.com>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
 <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
 <572F147B.7010300@plaimi.net>
 <3016DD2F-1BEC-4912-B686-05CE4872AFA2@cis.upenn.edu>
 <etPan.573003b7.1cde5c44.113@mbp.local>
 <m2lh3g8nog.fsf@newartisans.com>
Message-ID: <CAGK9nuoBNHXB2ggBaRdwCaYOXR9+Bsh9=niiGoB0kV2C_DxWjw@mail.gmail.com>

I disagree that we should be standardizing language features that have not
been implemented.

I think having an implementation is important because:
   1. the act of implementing a feature forces you to work out details that
you may not have thought of ahead of time.  For example, for a small
syntactic extension, the implementation would have to work out how to fit
it in the grammar, and how to present the new feature in, say, error
messages.
   2. having an implementation allows users to try out the extension and
gain some empirical evidence that the extension is actually useful in
practice (this is hard to quantify, I know, but it is even harder if you
can't even use the extension at all).

If some feature ends up being particularly useful, it could always be
standardized in the next iteration of the language, when we've gained some
experience using it in practice.

-Iavor



On Wed, May 11, 2016 at 11:17 AM, John Wiegley <johnw at newartisans.com>
wrote:

> >>>>> Gershom B <gershomb at gmail.com> writes:
>
> > While such changes should definitely be in scope, I do think that the
> proper
> > mechanism would be to garner enough interest to get a patch into GHC
> > (whether through discussion on the -prime list or elsewhere) and have an
> > experimental implementation, even for syntax changes, before such
> proposals
> > are considered ready for acceptance into a standard as such.
>
> Just a side note: This is often how the C++ committee proceeds as well: a
> language proposal with an experimental implementation is given much higher
> credence than paperware. However, they don't exclude paperware either.
>
> So I don't think we need to rely on implementation before considering a
> feature we all want, but I do agree that seeing a patch in GHC first allows
> for much testing and experimentation.
>
> --
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
> _______________________________________________
> 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/20160512/221fe8bf/attachment.html>

From iavor.diatchki at gmail.com  Thu May 12 19:48:59 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 12 May 2016 12:48:59 -0700
Subject: Limber separators
In-Reply-To: <wfh9eantp6.fsf@calligramme.charmers>
References: <572C97A5.3050308@plaimi.net> <wfh9eantp6.fsf@calligramme.charmers>
Message-ID: <CAGK9nupBZY4bLQWddbOECGxoKsbDKL7ADhM6kZHo9MGMvokOCA@mail.gmail.com>

On Sat, May 7, 2016 at 1:44 AM, Jon Fairbairn <jon.fairbairn at cl.cam.ac.uk>
wrote:

>
>
> The one this violates is ?never make language design decisions
> to work around deficiencies in tools? The problem is that diff
> does its work in ignorance of the syntax and consequently
> produces poor results.
>
>
I think that this is an excellent principle that we should uphold.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160512/a4e151bf/attachment.html>

From mail at andres-loeh.de  Thu May 12 20:25:35 2016
From: mail at andres-loeh.de (Andres Loeh)
Date: Thu, 12 May 2016 22:25:35 +0200
Subject: Scope of committee (can we do *new* things?)
In-Reply-To: <CAGK9nuoBNHXB2ggBaRdwCaYOXR9+Bsh9=niiGoB0kV2C_DxWjw@mail.gmail.com>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
 <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
 <572F147B.7010300@plaimi.net>
 <3016DD2F-1BEC-4912-B686-05CE4872AFA2@cis.upenn.edu>
 <etPan.573003b7.1cde5c44.113@mbp.local>
 <m2lh3g8nog.fsf@newartisans.com>
 <CAGK9nuoBNHXB2ggBaRdwCaYOXR9+Bsh9=niiGoB0kV2C_DxWjw@mail.gmail.com>
Message-ID: <CALjd_v5RCttboGL9bQTRSEkc=B3qR=-tJSiT0cO+m9nzEFrKTA@mail.gmail.com>

I think we all agree that in general, we should focus on existing
language extensions that have an implementation, and expect language
extensions to be implemented for them to be seriously considered for
inclusion in the standard.

But I think it would be wrong to turn this into a hard rule. Language
extensions are usually looked at in isolation, whereas the standard is
supposed to be a whole. There may be things that fit in well, are
useful generalizations of extensions we want to adopt, and so on that
are worth discussing. Also, extensions should perhaps be modified or
changed in some cases. If we say in advance that we can only
standardize things that GHC already implements, and only in exactly
this way, then it is a bit too limiting, and this would be throwing
away the chance to clean up a few issues.

The other side of this is that if we really arrive at the conclusion
that something should be different from the current GHC
implementations in any significant way, we should at least try to get
it implemented during, and not just after, the standardization process
so that we can still get practical feedback, and to prevent ending up
with a standard that will never be implemented.

Also (I think I've said this before), we should keep in mind that the
whole process for Haskell 2020 can have more outputs than just the new
standard itself. We can make progress towards standardization of
features in future versions of Haskell even if they don't yet make it.
We can make statements that we would in principle like to see certain
features in the standard, and identify the issues that currently
prevent them from being included.

Cheers,
  Andres

On Thu, May 12, 2016 at 9:46 PM, Iavor Diatchki
<iavor.diatchki at gmail.com> wrote:
> I disagree that we should be standardizing language features that have not
> been implemented.
>
> I think having an implementation is important because:
>    1. the act of implementing a feature forces you to work out details that
> you may not have thought of ahead of time.  For example, for a small
> syntactic extension, the implementation would have to work out how to fit it
> in the grammar, and how to present the new feature in, say, error messages.
>    2. having an implementation allows users to try out the extension and
> gain some empirical evidence that the extension is actually useful in
> practice (this is hard to quantify, I know, but it is even harder if you
> can't even use the extension at all).
>
> If some feature ends up being particularly useful, it could always be
> standardized in the next iteration of the language, when we've gained some
> experience using it in practice.
>
> -Iavor
>
>
>
> On Wed, May 11, 2016 at 11:17 AM, John Wiegley <johnw at newartisans.com>
> wrote:
>>
>> >>>>> Gershom B <gershomb at gmail.com> writes:
>>
>> > While such changes should definitely be in scope, I do think that the
>> > proper
>> > mechanism would be to garner enough interest to get a patch into GHC
>> > (whether through discussion on the -prime list or elsewhere) and have an
>> > experimental implementation, even for syntax changes, before such
>> > proposals
>> > are considered ready for acceptance into a standard as such.
>>
>> Just a side note: This is often how the C++ committee proceeds as well: a
>> language proposal with an experimental implementation is given much higher
>> credence than paperware. However, they don't exclude paperware either.
>>
>> So I don't think we need to rely on implementation before considering a
>> feature we all want, but I do agree that seeing a patch in GHC first
>> allows
>> for much testing and experimentation.
>>
>> --
>> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
>> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>> _______________________________________________
>> 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 eir at cis.upenn.edu  Fri May 13 13:34:16 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 13 May 2016 09:34:16 -0400
Subject: Scope of committee (can we do *new* things?)
In-Reply-To: <CALjd_v5RCttboGL9bQTRSEkc=B3qR=-tJSiT0cO+m9nzEFrKTA@mail.gmail.com>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
 <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
 <572F147B.7010300@plaimi.net>
 <3016DD2F-1BEC-4912-B686-05CE4872AFA2@cis.upenn.edu>
 <etPan.573003b7.1cde5c44.113@mbp.local> <m2lh3g8nog.fsf@newartisans.com>
 <CAGK9nuoBNHXB2ggBaRdwCaYOXR9+Bsh9=niiGoB0kV2C_DxWjw@mail.gmail.com>
 <CALjd_v5RCttboGL9bQTRSEkc=B3qR=-tJSiT0cO+m9nzEFrKTA@mail.gmail.com>
Message-ID: <6F035A6F-C6E0-472E-86E0-FA21928C9D33@cis.upenn.edu>

I strongly agree with all the points Andres makes here:
 - Focus on existing extensions
 - Permit discussion and even modification of existing behavior
 - Allow possibility of discussing new behavior
 - Strive hard to (or even require) an implementation before standardization (at the moment, time is on our side here)
 - Plan to include an appendix / co-report describing aspects of Haskell that are not yet strictly standardized

Richard

On May 12, 2016, at 4:25 PM, Andres Loeh <mail at andres-loeh.de> wrote:

> I think we all agree that in general, we should focus on existing
> language extensions that have an implementation, and expect language
> extensions to be implemented for them to be seriously considered for
> inclusion in the standard.
> 
> But I think it would be wrong to turn this into a hard rule. Language
> extensions are usually looked at in isolation, whereas the standard is
> supposed to be a whole. There may be things that fit in well, are
> useful generalizations of extensions we want to adopt, and so on that
> are worth discussing. Also, extensions should perhaps be modified or
> changed in some cases. If we say in advance that we can only
> standardize things that GHC already implements, and only in exactly
> this way, then it is a bit too limiting, and this would be throwing
> away the chance to clean up a few issues.
> 
> The other side of this is that if we really arrive at the conclusion
> that something should be different from the current GHC
> implementations in any significant way, we should at least try to get
> it implemented during, and not just after, the standardization process
> so that we can still get practical feedback, and to prevent ending up
> with a standard that will never be implemented.
> 
> Also (I think I've said this before), we should keep in mind that the
> whole process for Haskell 2020 can have more outputs than just the new
> standard itself. We can make progress towards standardization of
> features in future versions of Haskell even if they don't yet make it.
> We can make statements that we would in principle like to see certain
> features in the standard, and identify the issues that currently
> prevent them from being included.
> 
> Cheers,
>  Andres
> 
> On Thu, May 12, 2016 at 9:46 PM, Iavor Diatchki
> <iavor.diatchki at gmail.com> wrote:
>> I disagree that we should be standardizing language features that have not
>> been implemented.
>> 
>> I think having an implementation is important because:
>>   1. the act of implementing a feature forces you to work out details that
>> you may not have thought of ahead of time.  For example, for a small
>> syntactic extension, the implementation would have to work out how to fit it
>> in the grammar, and how to present the new feature in, say, error messages.
>>   2. having an implementation allows users to try out the extension and
>> gain some empirical evidence that the extension is actually useful in
>> practice (this is hard to quantify, I know, but it is even harder if you
>> can't even use the extension at all).
>> 
>> If some feature ends up being particularly useful, it could always be
>> standardized in the next iteration of the language, when we've gained some
>> experience using it in practice.
>> 
>> -Iavor
>> 
>> 
>> 
>> On Wed, May 11, 2016 at 11:17 AM, John Wiegley <johnw at newartisans.com>
>> wrote:
>>> 
>>>>>>>> Gershom B <gershomb at gmail.com> writes:
>>> 
>>>> While such changes should definitely be in scope, I do think that the
>>>> proper
>>>> mechanism would be to garner enough interest to get a patch into GHC
>>>> (whether through discussion on the -prime list or elsewhere) and have an
>>>> experimental implementation, even for syntax changes, before such
>>>> proposals
>>>> are considered ready for acceptance into a standard as such.
>>> 
>>> Just a side note: This is often how the C++ committee proceeds as well: a
>>> language proposal with an experimental implementation is given much higher
>>> credence than paperware. However, they don't exclude paperware either.
>>> 
>>> So I don't think we need to rely on implementation before considering a
>>> feature we all want, but I do agree that seeing a patch in GHC first
>>> allows
>>> for much testing and experimentation.
>>> 
>>> --
>>> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
>>> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>>> _______________________________________________
>>> 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 carter.schonwald at gmail.com  Fri May 13 14:02:18 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 13 May 2016 10:02:18 -0400
Subject: Scope of committee (can we do *new* things?)
In-Reply-To: <6F035A6F-C6E0-472E-86E0-FA21928C9D33@cis.upenn.edu>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
 <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
 <572F147B.7010300@plaimi.net>
 <3016DD2F-1BEC-4912-B686-05CE4872AFA2@cis.upenn.edu>
 <etPan.573003b7.1cde5c44.113@mbp.local>
 <m2lh3g8nog.fsf@newartisans.com>
 <CAGK9nuoBNHXB2ggBaRdwCaYOXR9+Bsh9=niiGoB0kV2C_DxWjw@mail.gmail.com>
 <CALjd_v5RCttboGL9bQTRSEkc=B3qR=-tJSiT0cO+m9nzEFrKTA@mail.gmail.com>
 <6F035A6F-C6E0-472E-86E0-FA21928C9D33@cis.upenn.edu>
Message-ID: <CAHYVw0zDa=KYbeaHJnbCxKfbwu0g9PFfUPcpcU4mJPzRifLy-A@mail.gmail.com>

On Friday, May 13, 2016, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> I strongly agree with all the points Andres makes here:
>  - Focus on existing extensions
>  - Permit discussion and even modification of existing behavior
>  - Allow possibility of discussing new behavior
>  - Strive hard to (or even require) an implementation before
> standardization (at the moment, time is on our side here)
>  - Plan to include an appendix / co-report describing aspects of Haskell
> that are not yet strictly standardized
>
> Richard
>
>
I second this summary and thus Andres' remarks.


> On May 12, 2016, at 4:25 PM, Andres Loeh <mail at andres-loeh.de
> <javascript:;>> wrote:
>
> > I think we all agree that in general, we should focus on existing
> > language extensions that have an implementation, and expect language
> > extensions to be implemented for them to be seriously considered for
> > inclusion in the standard.
> >
> > But I think it would be wrong to turn this into a hard rule. Language
> > extensions are usually looked at in isolation, whereas the standard is
> > supposed to be a whole. There may be things that fit in well, are
> > useful generalizations of extensions we want to adopt, and so on that
> > are worth discussing. Also, extensions should perhaps be modified or
> > changed in some cases. If we say in advance that we can only
> > standardize things that GHC already implements, and only in exactly
> > this way, then it is a bit too limiting, and this would be throwing
> > away the chance to clean up a few issues.
> >
> > The other side of this is that if we really arrive at the conclusion
> > that something should be different from the current GHC
> > implementations in any significant way, we should at least try to get
> > it implemented during, and not just after, the standardization process
> > so that we can still get practical feedback, and to prevent ending up
> > with a standard that will never be implemented.
> >
> > Also (I think I've said this before), we should keep in mind that the
> > whole process for Haskell 2020 can have more outputs than just the new
> > standard itself. We can make progress towards standardization of
> > features in future versions of Haskell even if they don't yet make it.
> > We can make statements that we would in principle like to see certain
> > features in the standard, and identify the issues that currently
> > prevent them from being included.
> >
> > Cheers,
> >  Andres
> >
> > On Thu, May 12, 2016 at 9:46 PM, Iavor Diatchki
> > <iavor.diatchki at gmail.com <javascript:;>> wrote:
> >> I disagree that we should be standardizing language features that have
> not
> >> been implemented.
> >>
> >> I think having an implementation is important because:
> >>   1. the act of implementing a feature forces you to work out details
> that
> >> you may not have thought of ahead of time.  For example, for a small
> >> syntactic extension, the implementation would have to work out how to
> fit it
> >> in the grammar, and how to present the new feature in, say, error
> messages.
> >>   2. having an implementation allows users to try out the extension and
> >> gain some empirical evidence that the extension is actually useful in
> >> practice (this is hard to quantify, I know, but it is even harder if you
> >> can't even use the extension at all).
> >>
> >> If some feature ends up being particularly useful, it could always be
> >> standardized in the next iteration of the language, when we've gained
> some
> >> experience using it in practice.
> >>
> >> -Iavor
> >>
> >>
> >>
> >> On Wed, May 11, 2016 at 11:17 AM, John Wiegley <johnw at newartisans.com
> <javascript:;>>
> >> wrote:
> >>>
> >>>>>>>> Gershom B <gershomb at gmail.com <javascript:;>> writes:
> >>>
> >>>> While such changes should definitely be in scope, I do think that the
> >>>> proper
> >>>> mechanism would be to garner enough interest to get a patch into GHC
> >>>> (whether through discussion on the -prime list or elsewhere) and have
> an
> >>>> experimental implementation, even for syntax changes, before such
> >>>> proposals
> >>>> are considered ready for acceptance into a standard as such.
> >>>
> >>> Just a side note: This is often how the C++ committee proceeds as
> well: a
> >>> language proposal with an experimental implementation is given much
> higher
> >>> credence than paperware. However, they don't exclude paperware either.
> >>>
> >>> So I don't think we need to rely on implementation before considering a
> >>> feature we all want, but I do agree that seeing a patch in GHC first
> >>> allows
> >>> for much testing and experimentation.
> >>>
> >>> --
> >>> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B
> B80F
> >>> http://newartisans.com                          60E1 46C4 BD1A 7AC1
> 4BA2
> >>> _______________________________________________
> >>> 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
> >>
>
> _______________________________________________
> 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/20160513/12106cfc/attachment.html>

From Henrik.Nilsson at nottingham.ac.uk  Sat May 14 10:00:59 2016
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Sat, 14 May 2016 11:00:59 +0100
Subject: Scope of committee (can we do *new* things?)
In-Reply-To: <6F035A6F-C6E0-472E-86E0-FA21928C9D33@cis.upenn.edu>
References: <572C97A5.3050308@plaimi.net> <572CD2BC.6000906@gmail.com>
 <572CF45B.7060109@plaimi.net>
 <CAF3RzK_CdegA+EGFde-xJTOvu=7MN9CHO7=zZM4MBoEZAXaYVg@mail.gmail.com>
 <CABUjdS4oJUDEsd-kMoX9U6AQh2O+Ww9mYW9KsvzLPUC2JkWOPg@mail.gmail.com>
 <572F147B.7010300@plaimi.net>
 <3016DD2F-1BEC-4912-B686-05CE4872AFA2@cis.upenn.edu>
 <etPan.573003b7.1cde5c44.113@mbp.local> <m2lh3g8nog.fsf@newartisans.com>
 <CAGK9nuoBNHXB2ggBaRdwCaYOXR9+Bsh9=niiGoB0kV2C_DxWjw@mail.gmail.com>
 <CALjd_v5RCttboGL9bQTRSEkc=B3qR=-tJSiT0cO+m9nzEFrKTA@mail.gmail.com>
 <6F035A6F-C6E0-472E-86E0-FA21928C9D33@cis.upenn.edu>
Message-ID: <5736F75B.6030807@nottingham.ac.uk>

Hi all,

I too basically agree with Andres's points and Richard's summary.

But there are a fair few existing extensions, and they are
not all equally compelling or urgent.

(Just to exemplify, multi-parameter type classes (which in practice
necessitates functional dependencies or broadly equivalent
functionality) and GADTs have been mentioned to me as particularly
urgent a fair few times.)

So, with risk of stating the obvious, a bit of care is needed to
decide just which existing extensions should be at the top of the
agenda.

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 anfelor at posteo.de  Wed May 18 19:10:53 2016
From: anfelor at posteo.de (Anton Felix Lorenzen)
Date: Wed, 18 May 2016 21:10:53 +0200
Subject: New Proposal: EasyMacros
In-Reply-To: <c8d41bda-b6a9-f29f-ee93-29b20bca7b91@posteo.de>
References: <c8d41bda-b6a9-f29f-ee93-29b20bca7b91@posteo.de>
Message-ID: <a31c71f7-ca27-91d6-deb9-28ade5402b90@posteo.de>

Hello list,

I want to propose a new way of writing template-haskell macros.
It is based on the idea, that syntax like this:
do {
    x <- getLine;
    putStrLn x;
}
should be parsed into:
$( do
    [ [| x <- getLine |]
    , [| putStrLn x   |]
    ] )
Then a function (do :: NonEmpty ExpQ -> ExpQ) will be called
and executed.

This would allow for a couple of useful macros:
   - do
   - case
   - fold -- fold the ExpQs into one, see below for details
   - eval -- evaluate ExpQs at compile-time
   - (maybe even) hamlet -- evaluate hamlet QQ
   - CPP replacements?

Nothing will be added which isn't possible today.
Nonetheless it will allow for a much cleaner syntax
and by this make things usable which weren't usable before.

Also it might be easier to implement new features.
For example ApplicativeDo and RecursiveDo
could have been implemented by a hackage package.
MultiWayIf could be a function, too.

apply
   [1..(10*365)]
   map (replicate 3)
   concat

conc
   "Hello World! \n"
   "How are you? \n"

Greetings,
Anton

===== Example Macros =====

see in context: https://github.com/anfelor/EasyMacros

conc = fold [| (++) |]
apply = fold [|flip ($)|]

fold :: ExpQ -- (a -> b -> c)
    -> NonEmpty (Q Exp) -> Q Exp
fold _ (a :| []) = a
fold fn (a :| b : xs) = fold fn (([| fn $a $b |]) :| xs)

do_ :: NonEmpty (Q Stmt) -> Q Exp
do_ (x :| []) = x >>= \case
      BindS _ _ -> fail "The last statement in a 'do' block must be an 
expression"
      NoBindS e -> return e
do_ (x :| xs) = x >>= \case
      BindS pat exp -> [| $(return exp) >>= \ $(return pat) -> $(do_ 
(fromList xs)) |]
      NoBindS   exp -> [| $(return exp) >> $(do_ (fromList xs)) |]

From eir at cis.upenn.edu  Wed May 18 21:09:31 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 18 May 2016 17:09:31 -0400
Subject: New Proposal: EasyMacros
In-Reply-To: <a31c71f7-ca27-91d6-deb9-28ade5402b90@posteo.de>
References: <c8d41bda-b6a9-f29f-ee93-29b20bca7b91@posteo.de>
 <a31c71f7-ca27-91d6-deb9-28ade5402b90@posteo.de>
Message-ID: <17BF3F4B-D54A-4C43-AA85-185AB8626303@cis.upenn.edu>

This strikes me as a more powerful form of RebindableSyntax, blazing new territory. (Existing RebindableSyntax never use Template Haskell.)

I assume you've emailed the Haskell Prime list because you wish this to be considered for inclusion in the next version of the standard. However, an extension this large would need to be vetted by implementation in a compiler (assumedly, GHC) before we can consider inclusion in a standard. If you wish to pursue this, I recommend generating a groundswell of interest from the community and writing a more formal proposal detailing exactly how such macros should be desugared into Template Haskell. You give an example below, and that is helpful, but we would need a more formal description.

This is, certainly, an interesting idea and would allow for yet more flexible extensions to the language, all without changing the compiler.

Thanks,
Richard

On May 18, 2016, at 3:10 PM, Anton Felix Lorenzen <anfelor at posteo.de> wrote:

> Hello list,
> 
> I want to propose a new way of writing template-haskell macros.
> It is based on the idea, that syntax like this:
> do {
>   x <- getLine;
>   putStrLn x;
> }
> should be parsed into:
> $( do
>   [ [| x <- getLine |]
>   , [| putStrLn x   |]
>   ] )
> Then a function (do :: NonEmpty ExpQ -> ExpQ) will be called
> and executed.
> 
> This would allow for a couple of useful macros:
>  - do
>  - case
>  - fold -- fold the ExpQs into one, see below for details
>  - eval -- evaluate ExpQs at compile-time
>  - (maybe even) hamlet -- evaluate hamlet QQ
>  - CPP replacements?
> 
> Nothing will be added which isn't possible today.
> Nonetheless it will allow for a much cleaner syntax
> and by this make things usable which weren't usable before.
> 
> Also it might be easier to implement new features.
> For example ApplicativeDo and RecursiveDo
> could have been implemented by a hackage package.
> MultiWayIf could be a function, too.
> 
> apply
>  [1..(10*365)]
>  map (replicate 3)
>  concat
> 
> conc
>  "Hello World! \n"
>  "How are you? \n"
> 
> Greetings,
> Anton
> 
> ===== Example Macros =====
> 
> see in context: https://github.com/anfelor/EasyMacros
> 
> conc = fold [| (++) |]
> apply = fold [|flip ($)|]
> 
> fold :: ExpQ -- (a -> b -> c)
>   -> NonEmpty (Q Exp) -> Q Exp
> fold _ (a :| []) = a
> fold fn (a :| b : xs) = fold fn (([| fn $a $b |]) :| xs)
> 
> do_ :: NonEmpty (Q Stmt) -> Q Exp
> do_ (x :| []) = x >>= \case
>     BindS _ _ -> fail "The last statement in a 'do' block must be an expression"
>     NoBindS e -> return e
> do_ (x :| xs) = x >>= \case
>     BindS pat exp -> [| $(return exp) >>= \ $(return pat) -> $(do_ (fromList xs)) |]
>     NoBindS   exp -> [| $(return exp) >> $(do_ (fromList xs)) |]
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


From anfelor at posteo.de  Thu May 19 09:20:50 2016
From: anfelor at posteo.de (Anton Felix Lorenzen)
Date: Thu, 19 May 2016 11:20:50 +0200
Subject: New Proposal: EasyMacros
In-Reply-To: <c31d60cd-9aed-bb99-85cf-0ad5a2c3da8d@posteo.de>
References: <c31d60cd-9aed-bb99-85cf-0ad5a2c3da8d@posteo.de>
Message-ID: <b88e30f8-dc79-1d5e-ff6f-339427970732@posteo.de>

I am glad you like the idea. I fully understand
that it should be an extension first, I simply followed the 
https://prime.haskell.org/wiki/Process

I am think I am not able to make a prime wiki page
(at least I wasn't able to find a button for this).

Should I create a ghc wiki page?
Email the Haskell-cafe list?

This is my first proposal and I m a bit lost here.

Thanks,
Anton

From me at lelf.lu  Tue May 31 13:42:14 2016
From: me at lelf.lu (Antonio Nikishaev)
Date: Tue, 31 May 2016 17:42:14 +0400
Subject: Limber separators
In-Reply-To: <CAGK9nupBZY4bLQWddbOECGxoKsbDKL7ADhM6kZHo9MGMvokOCA@mail.gmail.com>
References: <572C97A5.3050308@plaimi.net> <wfh9eantp6.fsf@calligramme.charmers>
 <CAGK9nupBZY4bLQWddbOECGxoKsbDKL7ADhM6kZHo9MGMvokOCA@mail.gmail.com>
Message-ID: <EC752EE4-558F-48AB-8F66-EF2873C4BD4F@lelf.lu>


> On 12 May 2016, at 23:48, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> 
> On Sat, May 7, 2016 at 1:44 AM, Jon Fairbairn <jon.fairbairn at cl.cam.ac.uk> wrote:
> 
> 
> The one this violates is ?never make language design decisions
> to work around deficiencies in tools? The problem is that diff
> does its work in ignorance of the syntax and consequently
> produces poor results.
> 
> 
> I think that this is an excellent principle that we should uphold.


Personally I don't need this extension per se since I don't care about one excess diff line.
What I do care about however, is the horrendous style people invented to avoid ?the diff problem?.
As an example

something = [ foo
	    , bar
	    , baz
	    ]

So I?d really like to see this extension, even if only to conquer the aforementioned style.



PS    But this all is indeed a little bikeshedding before we finish the ?Infrastructure & Communication? thread.



-- 
lelf


From iavor.diatchki at gmail.com  Tue May 31 17:50:54 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 31 May 2016 10:50:54 -0700
Subject: Infrastructure status?
Message-ID: <CAGK9nupfGVWOkt7f9U7xLnF740fryNGTsiZ1wFxftMry4XysPA@mail.gmail.com>

Hello,

what is the status of the discussion about how we should collaborate?   I
am not picky and would be happy to use whatever tools others prefer.  If it
was left to me, I'd use: 1) a git repo on github, which contains the
current version of the report, and various proposals, and 2) this e-mail
list for discussion.

As I said before, I think it might be quite nice as a first step to
standardize something simple, and hopefully not too controversial, so that
we can all familiarize ourselves with the basic process.

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160531/770a7c1e/attachment.html>

From hvriedel at gmail.com  Tue May 31 18:25:43 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 31 May 2016 20:25:43 +0200
Subject: Infrastructure status?
In-Reply-To: <CAGK9nupfGVWOkt7f9U7xLnF740fryNGTsiZ1wFxftMry4XysPA@mail.gmail.com>
 (Iavor Diatchki's message of "Tue, 31 May 2016 10:50:54 -0700")
References: <CAGK9nupfGVWOkt7f9U7xLnF740fryNGTsiZ1wFxftMry4XysPA@mail.gmail.com>
Message-ID: <87h9dew0d4.fsf@gmail.com>

Hello!

On 2016-05-31 at 19:50:54 +0200, Iavor Diatchki wrote:
> what is the status of the discussion about how we should collaborate?

> I am not picky and would be happy to use whatever tools others prefer.
> If it was left to me, I'd use: 1) a git repo on github, which contains
> the current version of the report, and various proposals, and 2) this
> e-mail list for discussion.

Coincidentally, GHC HQ is considering to revamp its process for
proposals as well, so I was holding off a bit to see what would come out
of it, as there's an understandable desire by GHC HQ to ideally share a
similiar/compatible process with the Haskell language+library committee
to make it easier to migrate proposals between the organisations. After
all, proposals starting out as GHC extension proposals are often
submitted with the agenda to re-propose them for inclusion into the
standard once they've been battle-proven.

Specifically, a variation of the Rust RFC process is being flirted with,
so that's quite similiar to what you're suggesting. While there were
concerns about GitHub being a proprietary service, I see little harm,
since there's APIs to extract/backup the relevant data from GitHub.

However, I'd strongly advise to not mix the report-git repo with the
proposals git repo, as that would result in a messy Git history.

I'd rather suggest to have 2 Git repos, to keep the concerns separate.
And I think we can just start out with such a 2nd GitHub repo and
make the process up as we go. At this point we should just get moving, as I
sense many of you want to finally start writing up proposals!

If this turns out to be a bad idea, we can just call it an instructive
failed experiment, and move the content into some other form.

If there's no objections, I suggest we create a
<https://github.com/haskell/rfcs> repository with a similiar basic
structure to <https://github.com/rust-lang/rfcs> and see how far we get
with that...


> As I said before, I think it might be quite nice as a first step to
> standardize something simple, and hopefully not too controversial, so
> that we can all familiarize ourselves with the basic process.