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

[Carter Schonwald]

On Friday, May 13, 2016, Richard Eisenberg <eir at 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 <mail at 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.diatchki at 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 <johnw at newartisans.com
> <javascript:;>>
> >> wrote:
> >>>
> >>>>>>>> Gershom B <gershomb at 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 at haskell.org <javascript:;>
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> >>
> >>
> >>
> >> _______________________________________________
> >> Haskell-prime mailing list
> >> Haskell-prime at haskell.org <javascript:;>
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> >>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160513/12106cfc/attachment.html>