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

[Andres Loeh]

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
>