Scope of committee (can we do *new* things?)

[Richard Eisenberg]

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