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

John Wiegley

2 May 2016 2 May '16

10:57 p.m.

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

Show replies by date

Carlton Mills

3 May 3 May

12:55 a.m.

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

Richard Eisenberg

1:33 a.m.

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

Austin Seipp

3:36 a.m.

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

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Michael Sloan

2:41 a.m.

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

Michael Sloan

2:47 a.m.

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

Gershom B

3:44 a.m.

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_wh... (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... 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_coh... 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 (johnw@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

Cale Gibbard

5:28 a.m.

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

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

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

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

...
I wonder if there are GHC extensions we'd like to promote as features in

On May 2, 2016 at 6:57:46 PM, John Wiegley (johnw@newartisans.com) wrote: 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

M Farkas-Dyck

5:32 a.m.

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.

Andres Loeh

6:12 a.m.

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

wren romano

4 May 4 May

4:48 a.m.

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 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? -- Live well, ~wren

Herbert Valerio Riedel

7:23 a.m.

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

wren romano

8 May 8 May

1:48 a.m.

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

Simon Peyton Jones

4 May 4 May

7:50 a.m.

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

Henrik Nilsson

8:21 a.m.

Hi all,

...

For example, much as I love GADTs and would be all for them being added in some future language report, I do not feel they should be added this time around. (Though I emphatically and wholeheartedly support adding GADTSyntax.)

In my opinion, GADTs is one of the most important extensions of the Haskell type system over the past decade and definitely a sweet spot in the design space in terms of power vs. complexity, at least from a user perspective. I eagerly await Herbert's summary of of most used extensions (which I think will be an extremely important input when deciding how to go forward in general), but my definite impression is that GADTs (and not just GADT syntax) are used a lot. Point taken about the difficulty of specifying GADT type inference declaratively. But as long as there at least is a way to standardise inference that works, and from what Simon said there is, I do think aiming to make GADTs an official part of Haskell 2020 should be a priority. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@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.

Richard Eisenberg

12:57 p.m.

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

Carter Schonwald

5 May 5 May

3:53 a.m.

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.Nilsson@nottingham.ac.uk javascript:;> wrote:

...
Hi all,

...
For example, much as I love GADTs and would be all for them being added in some future language report, I do not feel they should be added this time around. (Though I emphatically and wholeheartedly support adding GADTSyntax.)

In my opinion, GADTs is one of the most important extensions of the Haskell type system over the past decade and definitely a sweet spot in the design space in terms of power vs. complexity, at least from a user perspective. I eagerly await Herbert's summary of of most used extensions (which I think will be an extremely important input when deciding how to go forward in general), but my definite impression is that GADTs (and not just GADT syntax) are used a lot.

Point taken about the difficulty of specifying GADT type inference declaratively. But as long as there at least is a way to standardise inference that works, and from what Simon said there is, I do think aiming to make GADTs an official part of Haskell 2020 should be a priority.

Best,

/Henrik

-- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk javascript:;

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

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

M Farkas-Dyck

4 May 4 May

5 a.m.

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.

Dominique Devriese

6:51 a.m.

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

wren romano

8 May 8 May

1:39 a.m.

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

Simon Peyton Jones

9 May 9 May

8:18 a.m.

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-bounces@haskell.org] On | Behalf Of wren romano | Sent: 08 May 2016 02:40 | To: haskell-prime@haskell.org List | Subject: Re: Are there GHC extensions we'd like to incorporate | wholesale? | | 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 | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fhaskell- | prime&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd15df870d2b4441 | c57c808d376e19b35%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U2WAdUt4 | qXclT7F7G93J1zVylYv3CvhqNuNHeem%2fvEg%3d

Herbert Valerio Riedel

3 May 3 May

7:10 a.m.

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

Augustsson, Lennart

8:36 a.m.

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-bounces@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/financialmarke... for important information with respect to derivative products.

Herbert Valerio Riedel

8:50 a.m.

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

Augustsson, Lennart

8:57 a.m.

Then I suggest we keep EmptyDataDecls! -----Original Message----- From: Herbert Valerio Riedel [mailto:hvriedel@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/financialmarke... for important information with respect to derivative products.

Iavor Diatchki

4:14 p.m.

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.Augustsson@sc.com> wrote:

...

Then I suggest we keep EmptyDataDecls!

-----Original Message----- From: Herbert Valerio Riedel [mailto:hvriedel@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/financialmarke... 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

3344

Age (days ago)

3351

Last active (days ago)

List overview

Download

25 comments

17 participants

participants (17)

Andres Loeh
Augustsson, Lennart
Austin Seipp
Cale Gibbard
Carlton Mills
Carter Schonwald
Dominique Devriese
Gershom B
Henrik Nilsson
Herbert Valerio Riedel
Iavor Diatchki
John Wiegley
M Farkas-Dyck
Michael Sloan
Richard Eisenberg
Simon Peyton Jones
wren romano