On Friday, May 13, 2016, Richard Eisenberg <e...@cis.upenn.edu> wrote:
> 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 > > I second this summary and thus Andres' remarks. > On May 12, 2016, at 4:25 PM, Andres Loeh <m...@andres-loeh.de > <javascript:;>> 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 <javascript:;>> 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 > <javascript:;>> > >> wrote: > >>> > >>>>>>>> Gershom B <gersh...@gmail.com <javascript:;>> 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 <javascript:;> > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > >> > >> > >> > >> _______________________________________________ > >> Haskell-prime mailing list > >> Haskell-prime@haskell.org <javascript:;> > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > >> > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org <javascript:;> > 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