Are there GHC extensions we'd like to incorporate wholesale?

[Carter Schonwald]

Well said, having coherent location to collect bits per topic so they don't
get lost to mailing list thread mists of time is pretty important. I don't
care too much as long as it's easy to comment on a topic / ticket and or
propose edits. But probably something we should front load doing.

On Wednesday, May 4, 2016, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> There are many points I'd like to make in this discussion, but this one
> screams out the loudest:
>
> This thread is spiraling a bit out of control. I've seen useful
> conversations around many different extensions in here, but these
> conversations are sometimes only tangentially related. I'd personally much
> rather see us decide on a tool/process first, and then we can have
> someplace to have The GADT Discussion and another place to have The
> Overloaded Discussion, etc. Otherwise, we risk losing good points in this
> thread, and someone will have to comb through all of this to extract these
> good points.
>
> The discussion about what our goals are w.r.t. extensions -- whether to
> consider popularity, ease of specification, ease of implementation, making
> standard extensions, etc -- is, to me, more appropriate for this thread and
> this point in the process.
>
> So, might I humbly request that we focus our collective creative energies
> on having a stable process before getting into nitty-gritty details about
> extensions?
>
> Thanks,
> Richard
>
> On May 4, 2016, at 4:21 AM, Henrik Nilsson <
> Henrik.Nilsson at nottingham.ac.uk <javascript:;>> wrote:
>
> > Hi all,
> >
> > > For example, much as I love GADTs and would be all for them being
> > > added in some future language report, I do not feel they should be
> > > added this time around. (Though I emphatically and wholeheartedly
> > > support adding GADTSyntax.)
> >
> > In my opinion, GADTs is one of the most important extensions of the
> > Haskell type system over the past decade and definitely a sweet spot
> > in the design space in terms of power vs. complexity, at least from
> > a user perspective. I eagerly await Herbert's summary of of most used
> > extensions (which I think will be an extremely important input when
> > deciding how to go forward in general), but my definite impression is
> > that GADTs (and not just GADT syntax) are used a lot.
> >
> > Point taken about the difficulty of specifying GADT type inference
> > declaratively. But as long as there at least is a way to standardise
> > inference that works, and from what Simon said there is, I do think
> > aiming to make GADTs an official part of Haskell 2020 should be a
> > priority.
> >
> > Best,
> >
> > /Henrik
> >
> > --
> > Henrik Nilsson
> > School of Computer Science
> > The University of Nottingham
> > nhn at cs.nott.ac.uk <javascript:;>
> >
> >
> >
> >
> > This message and any attachment are intended solely for the addressee
> > and may contain confidential information. If you have received this
> > message in error, please send it back to me, and immediately delete it.
> > Please do not use, copy or disclose the information contained in this
> > message or in any attachment.  Any views or opinions expressed by the
> > author of this email do not necessarily reflect the views of the
> > University of Nottingham.
> >
> > This message has been checked for viruses but the contents of an
> > attachment may still contain software viruses which could damage your
> > computer system, you are advised to perform your own checks. Email
> > communications with the University of Nottingham may be monitored as
> > permitted by UK legislation.
> >
> > _______________________________________________
> > 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/20160504/3afb3920/attachment.html>