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.diatc...@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 <jo...@newartisans.com> > wrote: >> >> >>>>> Gershom B <gersh...@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@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 > _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
