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

Tue May 3 03:36:28 UTC 2016

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 <eir at cis.upenn.edu> 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" <johnw at 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at 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/