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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

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

Henrik Nilsson-2
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
[hidden email]




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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

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

Richard Eisenberg-2
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 <[hidden email]> 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
> [hidden email]
>
>
>
>
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Henrik.Nilsson@nottingham.ac.uk&#39;)">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
> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;nhn@cs.nott.ac.uk&#39;)">nhn@...
>
>
>
>
> 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
> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Haskell-prime@haskell.org&#39;)">Haskell-prime@...
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________
Haskell-prime mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Haskell-prime@haskell.org&#39;)">Haskell-prime@...
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

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

wren romano-2
In reply to this post by Dominique Devriese-2
On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese
<[hidden email]> wrote:
> 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?


FWIW, I'm against MonoLocalBinds. I understand the rational given in
the paper, but I disagree with it. In my experience the medicine is
worse than the disease.

It used to be that where-clauses where a nice clean way of organizing
code, especially for things like the worker/wrapper transform; but
with MonoLocalBinds all the benefits of where-clauses are eliminated.
For every local binding I'm forced to provide a type signature
—because part of the whole *point* of factoring things out is that
you're going to use them repeatedly, which for GADTs virtually
guarantees the uses will be at different index types and therefore
will require universal quantification— and these requisite type
signatures almost entirely duplicate information provided by the
signature for the primary/top-level binding. Indeed, in almost every
situation I end up needing to manually provide type signatures which
are identical to what let-generalization would have inferred. This
repetition is not merely annoying, it actively harms legibility and
maintainability of code.

--
Live well,
~wren
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

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

wren romano-2
In reply to this post by Herbert Valerio Riedel-3
On Wed, May 4, 2016 at 3:23 AM, Herbert Valerio Riedel
<[hidden email]> wrote:
> 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

I get that. My question was more because of how various things in the
Prelude are hard-coded into the rest of the report— in particular, the
core type classes feel like they span the boundary: the Monad class is
needed for the IO type for `main`, the fromInteger method of Num and
fromRational method of Fractional are needed for handling of numeric
literals, etc.

--
Live well,
~wren
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

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

Simon Peyton Jones
In reply to this post by wren romano-2
Just to be clear, MonoLocalBinds, as implemented, does not apply to local bindings that could equally well have been written at top level; that is, they do not mention any locally-bound variables (except other local bindings that could themselves be floated).

So you are at liberty to use where for stylistic reasons.

You may still dislike the cure, but the disease is pretty bad.  Do suggest alternative cures!

This is not to argue for or against MonoLocalBinds for Haskell Prime.

Simon

|  -----Original Message-----
|  From: Haskell-prime [mailto:[hidden email]] On
|  Behalf Of wren romano
|  Sent: 08 May 2016 02:40
|  To: [hidden email] List <[hidden email]>
|  Subject: Re: Are there GHC extensions we'd like to incorporate
|  wholesale?
|  
|  On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese
|  <[hidden email]> wrote:
|  > 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?
|  
|  
|  FWIW, I'm against MonoLocalBinds. I understand the rational given in
|  the paper, but I disagree with it. In my experience the medicine is
|  worse than the disease.
|  
|  It used to be that where-clauses where a nice clean way of organizing
|  code, especially for things like the worker/wrapper transform; but with
|  MonoLocalBinds all the benefits of where-clauses are eliminated.
|  For every local binding I'm forced to provide a type signature —because
|  part of the whole *point* of factoring things out is that you're going
|  to use them repeatedly, which for GADTs virtually guarantees the uses
|  will be at different index types and therefore will require universal
|  quantification— and these requisite type signatures almost entirely
|  duplicate information provided by the signature for the primary/top-
|  level binding. Indeed, in almost every situation I end up needing to
|  manually provide type signatures which are identical to what let-
|  generalization would have inferred. This repetition is not merely
|  annoying, it actively harms legibility and maintainability of code.
|  
|  --
|  Live well,
|  ~wren
|  _______________________________________________
|  Haskell-prime mailing list
|  [hidden email]
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fhaskell-
|  prime&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd15df870d2b4441
|  c57c808d376e19b35%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U2WAdUt4
|  qXclT7F7G93J1zVylYv3CvhqNuNHeem%2fvEg%3d
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
12