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

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

...

...

...

...

>> Gershom B 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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