Re: 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  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.nils...@nottingham.ac.uk > 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
> > n...@cs.nott.ac.uk 
> >
> >
> >
> >
> > 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@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

Re: Starting point for new standard?

[José Manuel Calderón Trilla]

Hello Christian,

On Wed, May 4, 2016 at 5:35 AM, Christian Siefkes  wrote:
> Hi all,
>
> out of curiosity, what'll be the starting point for the next Haskell report?
> I suppose Haskell 2010 plus the additional "No Datatype Contexts" change
> accepted by the old Haskell Language committee in early 2011 (see
> https://wiki.haskell.org/Haskell_2010#Additional_change )?

It hasn't been stated explicitly, but I would expect you're mostly correct.

The library portion of the standard is now under the purview of the
Core Libraries Committee (CLC) [1]. Therefore the current Haskell
Standard takes into account their work in addition to what you've
mentioned.

There's another thread on the mailing list about which extensions
deserve to be promoted to language features which might interest you,
but as far as I'm aware the assumed foundation is the 2010 report and
the work of the CLC.

Cheers,

Jose

[1]: https://wiki.haskell.org/Core_Libraries_Committee
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Starting point for new standard?

[Christian Siefkes]

Hi all,

out of curiosity, what'll be the starting point for the next Haskell report?
I suppose Haskell 2010 plus the additional "No Datatype Contexts" change
accepted by the old Haskell Language committee in early 2011 (see
https://wiki.haskell.org/Haskell_2010#Additional_change )?

Best regards
Christian

-- 
|- Dr. Christian Siefkes - christ...@siefkes.net -
| Homepage:   http://www.siefkes.net/   |   Blog:   http://www.keimform.de/
| Wie Produktion zur Nebensache wurde: www.keimform.de/2013/freie-quellen-1/
| Why Production No Longer Worries Us: www.keimform.de/2013/free-sources-1/
|--- OpenPGP Key ID: 0x980FA6ED --
2 + 2 = 5 for suitably large values of 2.




signature.asc
Description: OpenPGP digital signature
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

[Richard Eisenberg]

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  
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
> n...@cs.nott.ac.uk
> 
> 
> 
> 
> 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@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

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

[Henrik Nilsson]

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
n...@cs.nott.ac.uk




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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

[Simon Peyton Jones]

|  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.) The primary reason being that while the semantics of the
|  data types themselves is easy enough to define, there's no really
|  sensible way of specifying how type inference should work for them. GHC
|  has gone back and forth with a bunch of different inference methods
|  over the years, and I don't think that's really stabilized yet;

Actually it has stabilised.  The OutsideIn journal paper 
(http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/index.htm)
 describes how it works, and has been absolutely stable for several years.  
(All the movement has been on other things: type families, kind polymorphism, 
etc.)

I agree that the specification isn't entirely satisfactory, because it's a bit 
operational.  But it's robust and stable.

I'm not arguing for or against GADTs in the next iteration of Haskell.  But I 
don't think that the ease or difficulty of specifying GADTs is going to change 
much, so waiting till next time may not help; useful as they are, a declarative 
specification for GADTs is tricky.


Simon

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

[Herbert Valerio Riedel]

On 2016-05-04 at 06:48:38 +0200, wren romano wrote:

[...]

> Speaking of which, are things like the AMP and FTP under our purview
> or are they under the CLC?

I tried to clarify in the call-for-nomination and the formation
announcement that the library part of the Haskell Report shall be
formally under the CL(i)C's purview given their experience with
designing and implementing the big AMP/FTP/MFP proposals. In fact, I'd
like to think of the (extended) Prime Committee as being composed of two
sub-committee's: CLiC & CLaC (i.e. the Core Library Committee and Core
Language Committee). This gives each sub-committee a clear focus.

Of course, there'll sometimes be interactions (like
e.g. language-extensions/features to improve backward compatibility with
Haskell2010) between the language and the library part, so CLiC & CLaC
will have to talk to each other from time to time. It's also quite
possible that CLaC members may pick-up work-items from the CLiC or
vice-versa.

I know some of you consider the "Prelude" module as being morally a part
of the "language" rather than the library. But I'm sure the CLiC will
exercise extreme caution when the holy-grail "Prelude" module happens to
require adaptations and keep everyone in the loop. Not the least because
somebody may have alternative ideas how to achieve the goal differently
worth considering.

-- hvr
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

[Dominique Devriese]

As an outsider, I would like to suggest thinking about MonoLocalBinds.  GHC
has a rather convincing story (at least to me) that "(local) let should not
be generalised" (since it becomes problematic in combination with several
other language extensions) and the journal version of the OutsideIn(X)
paper has empirical data that indicates it is not a big problem to remove.
If there is a concern about backwards compatibility, perhaps the committee
could deprecate local let generalisation in Haskell2020 and remove it in a
subsequent iteration of the report?

Regards,
Dominique

Op wo 4 mei 2016 om 07:00 schreef M Farkas-Dyck :

> On 02/05/2016, Cale Gibbard  wrote:
> > This question implicitly has two parts:
> >
> > 1) Are there GHC extensions which the Report ought to describe in their
> > entirety? ...
> >
> > 2) Are there extensions which ought to stop being extensions? ...
>
> I agree here, except as noted in my earlier mail in this thread.
>
> An extension i might like to no longer be an extension is
> NoMonomorphismRestriction, which i haven't yet seen brought up in this
> thread. I recognize it has some rationale for it, but i surely want
> this committee to at least re-evaluate its merits.
> ___
> 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