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