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 <m...@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.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