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

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?

Re: 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 thenext report, as a starting point for discussing new additions.

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

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

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

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.

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

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.

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.

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

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.

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

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.

> 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" <[hidden email]> 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
>> [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>

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

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:

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.

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

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

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.

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:

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

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

On 02/05/2016, Cale Gibbard <[hidden email]> 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.

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

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.

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.

> On 02/05/2016, Cale Gibbard <[hidden email]> 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
> [hidden email]> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

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.

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

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.

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?

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.

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

> 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

> 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

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.

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

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

> 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

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.

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

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

I would hope that means that the platform will lean on contributors
to observe the new standard and curb exuberant use of extensions.
It would be wrong to blindly accept a selected corpus of existing
code as basis for a standard. (This is not to say that haskell prime
should ignore the practices of outstanding packages.)

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

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

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 constraints on instances without actually needing
any other type equality stuff that GHC does. While the problems I've
encountered with FlexibleInstances have mainly been due to non-linear
type variables, I could also see these delayed unification constraints
being helpful for the portion of FlexibleInstances which allows
non-variables to occur in argument positions; again because matching
on the top-level constructor of the instance head may be enough to
help us ground out the arguments to that constuctor, and we really
want to do that grounding after committing to using the instance
rather than as part of deciding whether to use the instance or not.

Overloaded* — If these are added I'd much rather have these as
"standard language extensions", i.e., they would still need to be
explicitly turned on, rather than being enabled everywhere. While it's
nice to have these extensions available, I very seldom need them, and
in light of that am a bit concerned about a backlash similar to the
one with the FTP.

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

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

On 02/05/2016, Cale Gibbard <[hidden email]> 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
[hidden email]http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

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?

On 02/05/2016, Cale Gibbard <[hidden email]> 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[hidden email]http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

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