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

[Simon Peyton Jones]

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:haskell-prime-boun...@haskell.org] On
|  Behalf Of wren romano
|  Sent: 08 May 2016 02:40
|  To: haskell-prime@haskell.org List <Haskell-prime@haskell.org>
|  Subject: Re: Are there GHC extensions we'd like to incorporate
|  wholesale?
|  
|  On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese
|  <dominique.devri...@cs.kuleuven.be> 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
|  Haskell-prime@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fhaskell-
|  prime=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd15df870d2b4441
|  c57c808d376e19b35%7c72f988bf86f141af91ab2d7cd011db47%7c1=U2WAdUt4
|  qXclT7F7G93J1zVylYv3CvhqNuNHeem%2fvEg%3d
___
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?

[wren romano]

On Wed, May 4, 2016 at 3:23 AM, Herbert Valerio Riedel
 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
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?

[wren romano]

On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese
 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
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?

[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: 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

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

[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

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

[wren romano]

On Tue, May 3, 2016 at 2:12 AM, Andres Loeh  wrote:
> Hi.
>
> Just to add a few general points. There are different dimensions to
> evaluate GHC extensions for inclusion in the standard, and just making
> lists does not really reflect that. The two most important ones, I
> think, are:
>
> 1. Whether we think they're actually a good idea or not.
>
> 2. Whether we think they're feasible to specify in a sensible way.
>
> There are variations of these points (extensions that are perhaps
> possible to specify, but ugly in their current form; extensions that
> have subtle interactions with others; ...)

I agree that these two points are what we should really be focusing on
(as well as things like ease of implementation), not just popularity.

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; so basically we'd be stuck with (a) not giving any
useful specification of what users can expect from inference / what
implementors must provide to be considered "standards compliant", or
(b) requiring some inference strategy that will stifle development
rather than help it.

Similarly, while TypeFamilies are fun to play with, I don't think
they're ready for primetime either. While in theory they are
equivalent to fundeps, in practice they're still playing catchup.
Given the choice, I'd much rather see fundeps be added to the spec,
where we make sure to phrase them in such a way that a viable
implementation could consider fundep syntax to be syntactic sugar for
some underlying story with TypeFamilies. —As for whether I'd actually
be given that choice in the first place, I know there have been issues
in the past about adding fundeps to the report. So far as I know, the
main concern is that implementing them correctly is quite intricate
(as also reflected in the intricacies of getting things like
injectivity for TypeFamilies working). But, if we think it'd be a good
idea to aim for getting some variant of type families into the
standard in a future version, then the complexity of fundeps is
already required (if we're to have a complete story for where
TypeFamilies is currently headed). So adding fundeps now does help
towards the eventual goal of adding type families; even if one day we
think of fundeps as a funny syntactic sugar, like how some of us
already consider the ADT syntax to be a funny syntactic sugar for the
more straightforward GADTSyntax.



> All this being said, I still have a personal list:
>
> BangPatterns
> ConstrainedClassMethods
> ConstraintKinds (?)
> Derive* (?)
> EmptyCase
> ExistentialQuantification
> ExplicitForAll
> ExplicitNamespaces
> ExtendedDefaultRules (?)
> FlexibleContexts
> FlexibleInstances
> GADTSyntax
> InstanceSigs
> KindSignatures
> NullaryTypeClasses
> Overloaded* (?)
> PartialTypeSignatures (?)
> RankNTypes
> ScopedTypeVariables
> StandaloneDeriving (?)
> TypeSynonymInstances
> TypeOperators (?)
>
> I probably forgot a few. For the ones listed with (?), I am aware of
> some problems, but I'd still be very happy to at least have some
> discussions about them and make some progress in the direction of
> future standardization, as I indicated above.


Many of these are on my personal hit list as well. And most of the
ones that aren't still seem fine to add; the exceptions being:

TypeSynonymInstances — I'm not a fan of this extension since it means
big warnings when teaching people Haskell (just getting them to
recognize that type-synonyms are mere shorthands and not generative
definitions is hard enough; any code using this extension requires
them to recognize that sooner). Though it people really want it...
::shrug::

ExtendedDefaultRules — may be okay, but I haven't used/needed it so
have never thought about it.

FlexibleInstances — I like this and want something very much like it,
but it's somewhat tricksy in practice so may need tweaking. In
particular, I've typically found that non-linear use of type variables
in the instance head is not in fact what people usually want/mean, and
so when such instances are given it leads to usability issues re
inference. Many times what is actually desired is to have a delayed
unification constraint, e.g. @instance (i ~ j) => Monad (IContT i j m)
where...@, where we first match the head (with only linear type
variables) and then after we've committed to selecting this instance
only then do we try to resolve the constraint. Even though the syntax
here is suggestive, I think we should be able to get away with adding
delayed unification 

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

[Iavor Diatchki]

Hello,

I think it'd be great to get started by specifying a few simple extensions,
such as the ones Lennart listed.  Even though they are very well
understood, and we have text about them in the GHC manual, we'd still have
to think of how to integrate their descriptions with the rest of the
report, and actually write the text.

I'd be happy to start working on any of these as soon as we've decided what
tools we'd like to use---I didn't follow the other thread closely, and I'd
be happy to use whatever people are comfortable with (as long as it works
on Linux, but I can't imagine that would be an issue).

-Iavor



On Tue, May 3, 2016 at 1:57 AM, Augustsson, Lennart <
lennart.augusts...@sc.com> wrote:

> Then I suggest we keep EmptyDataDecls!
>
> -Original Message-
> From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
> Sent: 03 May 2016 09:50
> To: Augustsson, Lennart
> Cc: John Wiegley; haskell-prime@haskell.org
> Subject: Re: Are there GHC extensions we'd like to incorporate wholesale?
>
> On 2016-05-03 at 10:36:31 +0200, Augustsson, Lennart wrote:
>
> > I'd say there are extensions we should just adopt wholesale, but they
> > are all of a very simple syntactic kind.
> >
> > E.g., EmptyDataDecls
>
> Btw, I have no idea why EmptyDataDecls keeps getting proposed for
> inclusion in the next report: `EmptyDataDecls` is one of the extensions
> that went into Haskell2010! :-)
>
> To quote Haskell2010, Ch. 12:
>
> | Those implementations are also encouraged to support the following
> | named language features:
> |
> | - PatternGuards,
> | - NoNPlusKPatterns,
> | - RelaxedPolyRec,
> | - EmptyDataDecls,
> | - ForeignFunctionInterface
> |
> | These are the named language extensions supported by some pre-Haskell
> | 2010 implementations, that have been integrated into this report.
>
>
> There's actually a few more deltas to H98 (like e.g. DoAndIfThenElse), so
>
>  {-# LANGUAGE Haskell2010 #-}
>
> is not equivalent to
>
>  {-# LANGUAGE Haskell98,
>   PatternGuards, NoNPlusKPatterns, RelaxedPolyRec,
>   EmptyDataDecls, ForeignFunctionInterface #-}
>
> But surprisingly this kind of information seems hard to find in the
> H2010 report.
>
> This email and any attachments are confidential and may also be
> privileged. If you are not the intended recipient, please delete all copies
> and notify the sender immediately. You may wish to refer to the
> incorporation details of Standard Chartered PLC, Standard Chartered Bank
> and their subsidiaries at
> http://www.standardchartered.com/en/incorporation-details.html
>
> Insofar as this communication contains any market commentary, the market
> commentary has been prepared by sales and/or trading desk of Standard
> Chartered Bank or its affiliate. It is not and does not constitute research
> material, independent research, recommendation or financial advice. Any
> market commentary is for information purpose only and shall not be relied
> for any other purpose, and is subject to the relevant disclaimers available
> at
> http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx
>
> Insofar as this e-mail contains the term sheet for a proposed transaction,
> by responding affirmatively to this e-mail, you agree that you have
> understood the terms and conditions in the attached term sheet and
> evaluated the merits and risks of the transaction. We may at times also
> request you to sign on the term sheet to acknowledge in respect of the same.
>
> Please visit
> http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
> for important information with respect to derivative products.
> ___
> 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?

[Augustsson, Lennart]

Then I suggest we keep EmptyDataDecls!

-Original Message-
From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com] 
Sent: 03 May 2016 09:50
To: Augustsson, Lennart
Cc: John Wiegley; haskell-prime@haskell.org
Subject: Re: Are there GHC extensions we'd like to incorporate wholesale?

On 2016-05-03 at 10:36:31 +0200, Augustsson, Lennart wrote:

> I'd say there are extensions we should just adopt wholesale, but they 
> are all of a very simple syntactic kind.
>
> E.g., EmptyDataDecls

Btw, I have no idea why EmptyDataDecls keeps getting proposed for inclusion in 
the next report: `EmptyDataDecls` is one of the extensions that went into 
Haskell2010! :-)

To quote Haskell2010, Ch. 12:

| Those implementations are also encouraged to support the following 
| named language features:
| 
| - PatternGuards,
| - NoNPlusKPatterns,
| - RelaxedPolyRec,
| - EmptyDataDecls,
| - ForeignFunctionInterface
| 
| These are the named language extensions supported by some pre-Haskell
| 2010 implementations, that have been integrated into this report.


There's actually a few more deltas to H98 (like e.g. DoAndIfThenElse), so

 {-# LANGUAGE Haskell2010 #-}

is not equivalent to

 {-# LANGUAGE Haskell98,
  PatternGuards, NoNPlusKPatterns, RelaxedPolyRec,  
  EmptyDataDecls, ForeignFunctionInterface #-}

But surprisingly this kind of information seems hard to find in the
H2010 report.

This email and any attachments are confidential and may also be privileged. If 
you are not the intended recipient, please delete all copies and notify the 
sender immediately. You may wish to refer to the incorporation details of 
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market 
commentary has been prepared by sales and/or trading desk of Standard Chartered 
Bank or its affiliate. It is not and does not constitute research material, 
independent research, recommendation or financial advice. Any market commentary 
is for information purpose only and shall not be relied for any other purpose, 
and is subject to the relevant disclaimers available at 
http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by 
responding affirmatively to this e-mail, you agree that you have understood the 
terms and conditions in the attached term sheet and evaluated the merits and 
risks of the transaction. We may at times also request you to sign on the term 
sheet to acknowledge in respect of the same.

Please visit 
http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
 for important information with respect to derivative products.
___
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?

[Augustsson, Lennart]

I'd say there are extensions we should just adopt wholesale, but they are all 
of a very simple syntactic kind.
E.g., EmptyDataDecls, ExplicitNamespaces, KindSignatures(?), NamedFieldPuns 
(used be part of Haskell), RecordWildcards(?), TupleSections, TypeOperators.

-Original Message-
From: Haskell-prime [mailto:haskell-prime-boun...@haskell.org] On Behalf Of 
John Wiegley
Sent: 02 May 2016 23:58
To: haskell-prime@haskell.org
Subject: Are there GHC extensions we'd like to incorporate wholesale?

I wonder if there are GHC extensions we'd like to promote as features in the 
next report, as a starting point for discussing new additions.

There are a few GHC features that have become part of the regular Haskell 
landscape, such that it's hard to imagine a modern Haskell without them. For 
example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.

How much "work" is typically involved in promoting a feature to be in the 
Report, and how do we determine when it's a bad idea?

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

This email and any attachments are confidential and may also be privileged. If 
you are not the intended recipient, please delete all copies and notify the 
sender immediately. You may wish to refer to the incorporation details of 
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market 
commentary has been prepared by sales and/or trading desk of Standard Chartered 
Bank or its affiliate. It is not and does not constitute research material, 
independent research, recommendation or financial advice. Any market commentary 
is for information purpose only and shall not be relied for any other purpose, 
and is subject to the relevant disclaimers available at 
http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by 
responding affirmatively to this e-mail, you agree that you have understood the 
terms and conditions in the attached term sheet and evaluated the merits and 
risks of the transaction. We may at times also request you to sign on the term 
sheet to acknowledge in respect of the same.

Please visit 
http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
 for important information with respect to derivative products.
___
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-03 at 00:57:38 +0200, John Wiegley wrote:
> I wonder if there are GHC extensions we'd like to promote as features
> in the next report, as a starting point for discussing new additions.
>
> There are a few GHC features that have become part of the regular
> Haskell landscape, such that it's hard to imagine a modern Haskell
> without them.

Btw, last year I computed a frequency-list of used extensions over
Hackage packages[1]. I'm planning to recompute such a list over all of
Hackage as well as over a Stackage subset. That would give us empirical
popularity data besides the subjective data provided by the recent
reddit discussion.

> For example, MultiParamTypeClasses, OverloadedStrings, GADTs,
> TypeFamilies, etc.
>
> How much "work" is typically involved in promoting a feature to be in the
> Report, and how do we determine when it's a bad idea?

As a concrete example of the problems formalising an extension, I'd like
to point to the example of 'BangPatterns' which may appear to be also
such a candidate and were considered for Haskell2014 already.

Back then, Ian hit some roadblocks:

  https://mail.haskell.org/pipermail/haskell-prime/2013-February/003782.html

Of course, I'm sure it would have been possible to resolve the open
issues with a bit more persistence. :-)


 [1]: https://gist.github.com/hvr/fd4fa2f10d4a10c7ebcc


-- 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?

[Andres Loeh]

Hi.

Just to add a few general points. There are different dimensions to
evaluate GHC extensions for inclusion in the standard, and just making
lists does not really reflect that. The two most important ones, I
think, are:

1. Whether we think they're actually a good idea or not.

2. Whether we think they're feasible to specify in a sensible way.

There are variations of these points (extensions that are perhaps
possible to specify, but ugly in their current form; extensions that
have subtle interactions with others; ...)

In general, I am in favour on working on extensions for which we
believe they're good ideas, and try to make progress, even if we
cannot include them yet. So just as an example, if we think GADTs (and
not just GADTSyntax) are in principle a good idea and should be in a
future standard, then perhaps we can try to work out what exactly we
feel would be needed to include them, but is still missing. Then even
in times when no standardization process is active, people can look at
this list of issues and try to work on them. I also think that we
should be careful with straight-forward looking syntax extensions.
Just because an extension is easy to specify should not make it an
automatic accept either. The complexity of the language is already
high.

All this being said, I still have a personal list:

BangPatterns
ConstrainedClassMethods
ConstraintKinds (?)
Derive* (?)
EmptyCase
ExistentialQuantification
ExplicitForAll
ExplicitNamespaces
ExtendedDefaultRules (?)
FlexibleContexts
FlexibleInstances
GADTSyntax
InstanceSigs
KindSignatures
NullaryTypeClasses
Overloaded* (?)
PartialTypeSignatures (?)
RankNTypes
ScopedTypeVariables
StandaloneDeriving (?)
TypeSynonymInstances
TypeOperators (?)

I probably forgot a few. For the ones listed with (?), I am aware of
some problems, but I'd still be very happy to at least have some
discussions about them and make some progress in the direction of
future standardization, as I indicated above.

Cheers,
  Andres

On Tue, May 3, 2016 at 7:32 AM, M Farkas-Dyck  wrote:
> On 02/05/2016, Cale Gibbard  wrote:
>> Are there extensions which ought to stop being extensions?
>
>> It may also be best to leave the answer up to the implementations. It is much
>> easier to argue for something like that once the extension has been on by
>> default in GHC and all other implementations for a while and most everyone
>> seems happy leaving it on.
>
> I think in many cases that would defeat the purpose of extensions.
> ___
> 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?

[M Farkas-Dyck]

On 02/05/2016, Cale Gibbard  wrote:
> Are there extensions which ought to stop being extensions?

> It may also be best to leave the answer up to the implementations. It is much
> easier to argue for something like that once the extension has been on by
> default in GHC and all other implementations for a while and most everyone
> seems happy leaving it on.

I think in many cases that would defeat the purpose of extensions.
___
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?

[Cale Gibbard]

This question implicitly has two parts:

1) Are there GHC extensions which the Report ought to describe in their
entirety? To this question, I would say "yes" - pretty much anything which
can be done in that direction will be productive, it's more a question of
what people are willing to put the work into.

2) Are there extensions which ought to stop being extensions? To this
question, I would argue it would be best to leave it for a time when the
extension is already fully described as an extension in the Report. It may
also be best to leave the answer up to the implementations. It is much
easier to argue for something like that once the extension has been on by
default in GHC and all other implementations for a while and most everyone
seems happy leaving it on.
On May 2, 2016 23:45, "Gershom B"  wrote:

> I agree that GHC extensions should be the starting point for new
> additions, as changes to the report should be based on established
> implementations (to ensure that changes are implementable and to ensure
> that they work out well for users).
>
> 1) background reading
>
> There were a few interesting threads on reddit the other day that may
> provide some fodder to think about.
>
> First, there was a survey of what extensions that people found useful and
> would like incorporated, as well as their concerns:
>
>
> https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/
>
> (Feel free to disregard the confusion of how they described “Haskell2016”
> and the like for something closer to glasgow-exts-2016, as its extraneous
> to what makes this interesting).
>
> Second, the summary thread on the results:
>
>
> https://www.reddit.com/r/haskell/comments/4ggp8z/summary_of_the_xhaskell2016_feedback/
>
> The summary results give a good indication of what extensions there might
> seem to be the most widespread sentiment to standardize.
>
> This thread also gives a link to Reid Barton’s lovely example of how
> FlexibleInstances can be used to violate coherence:
> https://www.reddit.com/r/haskell/comments/2agy14/type_classes_confluence_coherence_global/civ6y1g
>
> The same trick is supposed to apply to MPTCs. (In both cases, I imagine
> there can be a “fixup” that would prevent this, but that’s for another
> discussion).
>
> 2) suggestions for proceeding
>
> In any case, it seems to me (as a non-prime-committee member) that it
> would be good to proceed in two parallel tracks.
>
> First: A victim^H^H^H^H^H^H volunteer to pick a particularly low-hanging
> fruit (lambdacase, tuple sections, binary literals) and try to do a
> test-run of the proposal process to work out the kinks and set an example
> for others to follow. Perhaps a few could be worked on by different people
> at once. (As a datapoint, here is I think how an accepted proposal looked
> under the H2010 process: https://prime.haskell.org/wiki/NoNPlusKPatterns)
> (And I see that Austin has already volunteered! wonderful!)
>
> Second: Some high-level effort to categorize and pull together a
> dependency graph of the other extensions. A googledoc spreadsheet or a
> trello board might be a good “work arena” for this. I would want to
> separate extensions into for example buckets like “pure syntax” “typeclass
> related” “monad syntax” “deriving related” “higher-rank related” “record
> related” “concurrency related”. The idea would be that things in the same
> bucket would have a higher chance of interacting / potentially needing to
> be treated in tandem. That way, areas could be tackled at once, and the
> committee could “burndown” easy stuff, while perhaps individuals with
> expertise might want to try to work on the side to find “minimal, safe”
> paths through the thicket of complex extensions. (standardizing GADT syntax
> without yet adding type equality constraints to enable actual GADTs is a
> good example here. Another _might_ be for example allowing RankNTypes but
> specifying that compliant compilers need only accept such type signatures
> fully specified, but could optionally go above and beyond in inference,
> etc). Note that more complex proposals could always be worked out by
> interest groups working by themselves, and only presented to a larger
> audience once some kinks were ironed out, etc.
>
> Cheers,
> Gershom
>
>
>
> On May 2, 2016 at 6:57:46 PM, John Wiegley (jo...@newartisans.com) wrote:
> > I wonder if there are GHC extensions we'd like to promote as features in
> the
> > next report, as a starting point for discussing new additions.
> >
> > There are a few GHC features that have become part of the regular Haskell
> > landscape, such that it's hard to imagine a modern Haskell without them.
> For
> > example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies,
> etc.
> >
> > How much "work" is typically involved in promoting a feature to be in the
> > Report, and how do we determine when it's a bad idea?
> >
> > --
> > John Wiegley GPG fingerprint = 4710 CF98 

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

[Gershom B]

I agree that GHC extensions should be the starting point for new additions, as 
changes to the report should be based on established implementations (to ensure 
that changes are implementable and to ensure that they work out well for users).

1) background reading

There were a few interesting threads on reddit the other day that may provide 
some fodder to think about.

First, there was a survey of what extensions that people found useful and would 
like incorporated, as well as their concerns:

https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/

(Feel free to disregard the confusion of how they described “Haskell2016” and 
the like for something closer to glasgow-exts-2016, as its extraneous to what 
makes this interesting).

Second, the summary thread on the results:

https://www.reddit.com/r/haskell/comments/4ggp8z/summary_of_the_xhaskell2016_feedback/

The summary results give a good indication of what extensions there might seem 
to be the most widespread sentiment to standardize.

This thread also gives a link to Reid Barton’s lovely example of how 
FlexibleInstances can be used to violate coherence: 
https://www.reddit.com/r/haskell/comments/2agy14/type_classes_confluence_coherence_global/civ6y1g

The same trick is supposed to apply to MPTCs. (In both cases, I imagine there 
can be a “fixup” that would prevent this, but that’s for another discussion).

2) suggestions for proceeding

In any case, it seems to me (as a non-prime-committee member) that it would be 
good to proceed in two parallel tracks.

First: A victim^H^H^H^H^H^H volunteer to pick a particularly low-hanging fruit 
(lambdacase, tuple sections, binary literals) and try to do a test-run of the 
proposal process to work out the kinks and set an example for others to follow. 
Perhaps a few could be worked on by different people at once. (As a datapoint, 
here is I think how an accepted proposal looked under the H2010 process: 
https://prime.haskell.org/wiki/NoNPlusKPatterns) (And I see that Austin has 
already volunteered! wonderful!)

Second: Some high-level effort to categorize and pull together a dependency 
graph of the other extensions. A googledoc spreadsheet or a trello board might 
be a good “work arena” for this. I would want to separate extensions into for 
example buckets like “pure syntax” “typeclass related” “monad syntax” “deriving 
related” “higher-rank related” “record related” “concurrency related”. The idea 
would be that things in the same bucket would have a higher chance of 
interacting / potentially needing to be treated in tandem. That way, areas 
could be tackled at once, and the committee could “burndown” easy stuff, while 
perhaps individuals with expertise might want to try to work on the side to 
find “minimal, safe” paths through the thicket of complex extensions. 
(standardizing GADT syntax without yet adding type equality constraints to 
enable actual GADTs is a good example here. Another _might_ be for example 
allowing RankNTypes but specifying that compliant compilers need only accept 
such type signatures fully specified, but could optionally go above and beyond 
in inference, etc). Note that more complex proposals could always be worked out 
by interest groups working by themselves, and only presented to a larger 
audience once some kinks were ironed out, etc.

Cheers,
Gershom



On May 2, 2016 at 6:57:46 PM, John Wiegley (jo...@newartisans.com) wrote:
> I wonder if there are GHC extensions we'd like to promote as features in the
> next report, as a starting point for discussing new additions.
>  
> There are a few GHC features that have become part of the regular Haskell
> landscape, such that it's hard to imagine a modern Haskell without them. For
> example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.  
>  
> How much "work" is typically involved in promoting a feature to be in the
> Report, and how do we determine when it's a bad idea?
>  
> --
> 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
> 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?

[Austin Seipp]

IMO, the committee should not focus on most these at the moment,
because there are easier wins to be had - most of the open proposed
ones have problems that make the discussion veer from "Very Obvious"
to "Not so obvious". I know they're popular, but doing this is going
to require a lot more discussion.

A few points:

  - MPTCs. I'm OK with this by itself but it's not very useful without
some constituent thing like Fundeps or type families. Richard, when
you say there's an incoherence problem, can you be more specific? The
more recent one I was reminded of was that FlexibleInstances can
violate coherence, but that's a bit more subtle - maybe that's what
you meant? I'm not sure if it's enough to keep it out. See
https://gist.github.com/rwbarton/dd8e51dce2a262d17a80 for an example.

  - OverloadedStrings are less trivial than you think. Because:

$ ghci
GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
Prelude> :set -XOverloadedStrings
Prelude> length "foo"

:3:1:
No instance for (Foldable t0) arising from a use of ‘length’
The type variable ‘t0’ is ambiguous
...

  Yes, I know, the FTP, etc etc etc. However, that makes a lot of
simple code examples break in the case of overloaded functions that
can't pick the right base type. There's obviously still some back and
forth to be done, perhaps the FTP could be refined for Haskell2020.
Anyway, my point is this is less initially trivial than it might seem
to some.

  - GADTs are an extension I like dearly, but I think they are also
not so simple. I think the Haskell report is fairly careful, as it
stands, not to dictate much about inference strategies. GADTs surface
these changes, for example, by ensuring let is not generalized. I
think the committee could come to something on this perhaps, but it is
not so simple. Deviating from this is something we can decide to do,
but not easily.

  - Richard touched on it only as an side, but GADT syntax would be
excellent. I would even like it to be enshrined by the standard as the
default (perhaps modulo ExistentialQuantification). In fact I like it
so much that it gets its own bullet point. That's for another day,
just saying.

  - Type families, I think, are not as well understood and have
changed far too quickly, in recent memory, to talk about this early
on, as Richard said.

I think that at the moment we should focus on making the process easy
so we can keep our motivation up. Taking on large extensions is going
to lead to bikeshedding and drain people, I think, which would be a
real bad thing to happen after so much hubbub. I know many people on
the committee are probably going to have feelings similar to the
above.

If we are going to talk about "wholesale incorporation", there are
many simplier, much more obvious extensions. Plus, these will give us
a chance to go at the process and try to find something that works for
us. Or at least makes us all equally unhappy (the definition of good
compromise). Much easier to test out how we want things to go when the
stakes are much lower.

I like the list Michael Sloan suggested elsewhere, or something like
it. Many many more obvious extensions to be had:

  - RecursiveDo
  - LambdaCase
  - TupleSections (surprisingly popular, in the "would use frequently
if always on"-category, it seems)
  - GADTSyntax (already definitively asserted as great)
  - BinaryLiterals
  - EmptyCase
  - InstanceSigs
  - ParallelListComp

I seem to remember MultiWayIf having some kind of weird interaction
with the lexer to make it abide by the proper block rules, but I'd
probably also vote for it anyway.

I intentionally left off anything that didn't seem somewhat blindingly
obvious, and some that you might think suspiciously absent I know for
a fact someone might pipe up and say "But wait!" -- Anyway, the point
is to get some easy wins. Maybe others are ones we incorporate
wholesale too, but let's just target a couple really clear ones.

The thread about the RFC/editing process is still ongoing, but I think
we could easily add the above ones with only a couple rounds of
intense, heated debate, and that would be a good warm up.

Traditionally, I think proposals were actually sent including what
were basically literal deltas to the Haskell Report, pretty much,
including how it would be described and added. Obviously we want
source control to do that now.

I'd be willing to be a guinea pig and submit a couple of the above
ones for some trial runs on the process, if people think this is an OK
place to start. We'll probably have to nail the exact RFC method down,
though, in the other thread on the list. I also probably wouldn't get
to it until the end of this week, so that's likely for the best
anyway.

On Mon, May 2, 2016 at 8:33 PM, Richard Eisenberg  wrote:
> Great questions. Here's my take:
>
> For something to be incorporated into the standard, we'd need to be able to 
> give a concrete, precise description of how the extension changes the set of 
> 

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

[Michael Sloan]

Doh, left off MultiParamTypeClasses from the list in the email.  Though, as
Richard mentions, apparently this should be carefully considered with
regards to coherence.

On Mon, May 2, 2016 at 7:41 PM, Michael Sloan  wrote:

> In this issue on the hpack tracker, I describe my swing at coming up with
> a conservative set of extensions:
>
> https://github.com/sol/hpack/issues/94
>
> The list I ended up with is:
>
> LambdaCase, GADTSyntax, ScopedTypeVariables, TupleSections, BangPatterns,
> FlexibleInstances, FlexibleContexts, MultiWayIf, TypeOperators,
> FunctionalDependencies,
> BinaryLiterals, RecursiveDo, ParallelListComp, PartialTypeSignatures,
> EmptyCase, InstanceSigs
>
> Not sure about FlexibleInstances, EmptyCase, or TupleSections (see the
> issue).
>
> If some set like this is accepted, then that "just" leaves figuring out
> the set of more complicated type system extensions :)
>
> -Michael
>
> On Mon, May 2, 2016 at 3:57 PM, John Wiegley 
> wrote:
>
>> I wonder if there are GHC extensions we'd like to promote as features in
>> the
>> next report, as a starting point for discussing new additions.
>>
>> There are a few GHC features that have become part of the regular Haskell
>> landscape, such that it's hard to imagine a modern Haskell without them.
>> For
>> example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies,
>> etc.
>>
>> How much "work" is typically involved in promoting a feature to be in the
>> Report, and how do we determine when it's a bad idea?
>>
>> --
>> 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
>> 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?

[Michael Sloan]

In this issue on the hpack tracker, I describe my swing at coming up with a
conservative set of extensions:

https://github.com/sol/hpack/issues/94

The list I ended up with is:

LambdaCase, GADTSyntax, ScopedTypeVariables, TupleSections, BangPatterns,
FlexibleInstances, FlexibleContexts, MultiWayIf, TypeOperators,
FunctionalDependencies,
BinaryLiterals, RecursiveDo, ParallelListComp, PartialTypeSignatures,
EmptyCase, InstanceSigs

Not sure about FlexibleInstances, EmptyCase, or TupleSections (see the
issue).

If some set like this is accepted, then that "just" leaves figuring out the
set of more complicated type system extensions :)

-Michael

On Mon, May 2, 2016 at 3:57 PM, John Wiegley  wrote:

> I wonder if there are GHC extensions we'd like to promote as features in
> the
> next report, as a starting point for discussing new additions.
>
> There are a few GHC features that have become part of the regular Haskell
> landscape, such that it's hard to imagine a modern Haskell without them.
> For
> example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies,
> etc.
>
> How much "work" is typically involved in promoting a feature to be in the
> Report, and how do we determine when it's a bad idea?
>
> --
> 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
> 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?

[Richard Eisenberg]

Great questions. Here's my take:

For something to be incorporated into the standard, we'd need to be able to 
give a concrete, precise description of how the extension changes the set of 
correct Haskell programs. We also need to consider how the extension changes 
properties of the language, like predictability of performance or class 
coherence.

For the four you mention, here are my thoughts:

MultiParamTypeClasses: Can't these be used to create incoherence? I seem to 
recall hearing this once. I'm in general in favor of including these, but would 
want to reflect on the coherence question a bit.

OverloadedStrings: This seems very straightforward. But it's quite easy to 
conceive of times when I wouldn't want this feature in the language. If the 
extension becomes part of the standard, is there a way to turn it off? If not, 
Haskell2020 would not be a conservative extension of Haskell2010.

GADTs: While GADTSyntax seems straightforward, GADT type inference is far from. 
Do we have a description of GADT type inference that doesn't rely on thinking 
about variable unification? Even if we're OK putting unification into the 
standard, GHC's current inference capabilities are still not very finely 
mapped. (Note that the inference algorithm in the OutsideIn paper is incomplete 
with respect to the specification in that paper.)

TypeFamilies: I think there's quite a bit more to understand about type 
families before they could be standardized. First off, they come in many 
flavors (associated, open, closed). Do we want to include all of the flavors? 
How do partial type families really operate? I wrote a blog post [1] exploring 
this topic and had more questions than answers. What about termination 
checking? Or do we want to allow non-terminating definitions and discard 
decidability of type inference?

Of course, I recognize that John picked just a few arbitrary popular 
extensions. But even these extensions have a lot of dark corners, and my 
answers above are just to highlight that there's real work to be done, even 
with very popular extensions.

Richard

[1]: https://typesandkinds.wordpress.com/2015/09/09/what-are-type-families/

On May 2, 2016, at 6:57 PM, "John Wiegley"  wrote:

> I wonder if there are GHC extensions we'd like to promote as features in the
> next report, as a starting point for discussing new additions.
> 
> There are a few GHC features that have become part of the regular Haskell
> landscape, such that it's hard to imagine a modern Haskell without them. For
> example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.
> 
> How much "work" is typically involved in promoting a feature to be in the
> Report, and how do we determine when it's a bad idea?
> 
> -- 
> 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
> 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?

[Carlton Mills]

One objective would be to compile the Haskel Platform with near zero 
extensions. 

On Monday, May 2, 2016 5:57 PM, John Wiegley  wrote:
 

 I wonder if there are GHC extensions we'd like to promote as features in the
next report, as a starting point for discussing new additions.

There are a few GHC features that have become part of the regular Haskell
landscape, such that it's hard to imagine a modern Haskell without them. For
example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.

How much "work" is typically involved in promoting a feature to be in the
Report, and how do we determine when it's a bad idea?

-- 
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
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