[ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension?

Fri Oct 20 00:59:34 UTC 2017

>The plan with LANGUAGE extensions was that they do migrate into the standard when they are stable. This is no longer going to happen. Hence, *we* owe it to GHC’s users to make that determination on an extension by extension basis and enforce it through the proposals process.

I agree.

>Now, we can discuss the details:
>* What categories are there?
>* How long do extensions remain agile?
>* How do we make the determination when to promote an extension to a more stable category?

My suggestion would be to keep the categories minimal and focused on
the way they function in the compiler-as-user-interface:

- Must be manually enabled. We can (should?) accompany unstable or
potentially unsafe extensions with warnings describing those caveats,
but I don't think building an ontology of stableness would be
productive.
- Must be manually disabled. I would love to nominate
ScopedTypeVariables for this but I'm sure there are caveats to STV I
haven't yet encountered. This status implies the extension is a
candidate for eventual incorporation.
- Incorporated. Cannot be disabled in GHC Haskell, considered part of
the language (standard?) proper now.

If you wanted to extend an extension in the defaulted state, you would
create a new extension and it starts at the first stage. The new
extension modifying an existing feature must prove itself to be stable
and worthwhile of defaulting or later incorporation independently of
the feature it modified.

>* Can we agree that we cannot leave it solely to extension authors to assign stabilities? (In particular, we already have lots of extensions and we need to take care of those.)
>Why not leave it to extension authors? They have no (direct) interest in stability. We are the gate keepers. It is our job.

I agree with this, extension authors cannot be solely responsible for
ascertaining how stable something is or where it is on the path to
becoming defaulted or incorporated.

>PPS: This is also very much a beginner issue. Experts know from experience which extensions are stable. Newcomers often ask, what can I safely use? It’s not spelled out anywhere. (Ping Chris.)

There are three main areas where the extensions issue tends to rankle me:

1. As a working user of Haskell that touches a lot of libraries, does
a lot of throw-away projects as experiments, I've had to start using
hpack (http://hackage.haskell.org/package/hpack) to generate my Cabal
files. Some of the motivation for that has been to have a single
global list of default-extensions that apply to all of the project's
build/test/bench target stanzas. I do this often enough that I copy
and paste the default-extensions list between projects not even
bothering to weed out the unnecessary ones on the assumption I'll need
them eventually anyway. This might seem careless but I toss up a lot
of experiments, tutorials, and demonstrations and I don't want to keep
having to restart my REPL session because I forgot something. Example
of my copied-and-pasted default-extensions:

default-extensions:
- ConstraintKinds
- DataKinds
- DeriveFunctor
- DeriveGeneric
- FlexibleContexts
- FlexibleInstances
- FunctionalDependencies
- GADTs
- ImplicitParams
- LambdaCase
- MultiParamTypeClasses
- OverloadedStrings
- PartialTypeSignatures
- QuasiQuotes
- RankNTypes
- RecordWildCards
- TemplateHaskell
- TypeFamilies
- TypeOperators
- ScopedTypeVariables
- UndecidableInstances

I realize not all of these are benign. I'll cross that bridge when it
someday bites me after over 5 years of using Haskell. I think the only
nasty/dead-end ones I've run into have been incoherent instances (Hail
Oleg) and impredicative types. Which I hear could be fixed maybe?
That'd be neat.

FWIW, SafeHaskell is not representative of what's considered "safe"
for GHC extensions among the Haskell users I talk to. Different
understanding/standard of "safe", possibly partly because we don't
have reproducible builds anyway?

Stephen Diehl's Haskell tutorial is the usual citation for what
extensions are benign/potentially dangerous:
http://dev.stephendiehl.com/hask/#the-benign

2. Extensions get weaponized in PL polemics as incontrovertible proof
of how "complicated" GHC Haskell is or how much Haskell "needs" before
it's a complete language. I admit this isn't strictly within our remit
but it is very tiresome.

3. #2 then leads to: new people terrified of turning on an extension
even when it's benign and exactly what they want to do at that
particular moment. Even in cases where GHC is telling them to do it.
Related to new-people-fear is new users believing extensions must be
hopelessly complicated if they extend an already seemingly
difficult-to-learn language.

I don't think we'll ever be totally rid of extensions and I'm not sure
it'd be a good thing if we were. If we could make extension-spam the
exception rather than the rule on the non-libraries I work on I think
that would be a tremendous improvement to peoples' perception of
complexity and difficulty. And to be clear, I think it's mostly
perception. I've been able to teach RankNTypes to otherwise new
Haskell users quite successfully in the past, with the main
prerequisites being a sound understanding of polymorphism and variable
binding.

Thank you Manuel, this is great.

On Wed, Oct 18, 2017 at 8:08 PM, Manuel M T Chakravarty
<chak at justtesting.org> wrote:
> If I may summarise the last few messages on this thread, it seems to me that, so far, everybody agrees that it would be beneficial to have two or more categories of extensions that come with different expectations of stability. (Whether that is by marking them as stable or annotating them with versions or years are details we will figure out.)
>
> Richard, I do understand your fear about not being able to move quickly, and I think, we all want to preserve that property of Haskell. However, I would like us to think about how we can preserve agility, while providing sufficient stability. (I know that is hard, but easy problems are boring, so let’s rise to the challenge.)
>
> As I said, in my previous message, I consider Haskell Prime to be dead (for all practical purposes). There will be no more Haskell standard. The closest thing to a Haskell standards committee —namely, the ”GHC Haskell” standards committee— is this group!
>
> The plan with LANGUAGE extensions was that they do migrate into the standard when they are stable. This is no longer going to happen. Hence, *we* owe it to GHC’s users to make that determination on an extension by extension basis and enforce it through the proposals process.
>
> Now, we can discuss the details:
>
> * What categories are there?
> * How long do extensions remain agile?
> * How do we make the determination when to promote an extension to a more stable category?
>
> Before we get too tied up in the details, I would like to discuss two higher-order points:
>
> * Do we all agree that we need categories of stabilities for extensions (for the reasons outlined above)?
> * Can we agree that we cannot leave it solely to extension authors to assign stabilities? (In particular, we already have lots of extensions and we need to take care of those.)
>
> Why not leave it to extension authors? They have no (direct) interest in stability. We are the gate keepers. It is our job.
>
> Cheers,
> Manuel
>
> PS: There is also the issue of libraries, but that is really the responsibilities of the Core Libraries Committee (and maybe we have to have a chat with them).
>
> PPS: This is also very much a beginner issue. Experts know from experience which extensions are stable. Newcomers often ask, what can I safely use? It’s not spelled out anywhere. (Ping Chris.)
>
>> Richard Eisenberg <rae at cs.brynmawr.edu>:
>>> On Oct 18, 2017, at 4:49 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>>
>>> The way out there might be to try our best, and if we get it wrong and
>>> mark an extension as stable too early, we’ll just have to add a new
>>> pragma for the improved ones… so that seems like a good compromise.
>>>
>>
>> Yes, this is exactly what I was thinking. For example, TypeFamilies might have been marked as stable before closed type families came about... but then we would just have -XClosedTypeFamilies -- not so horrible.
>>
>>> The other failure mode would be that we will have _too strict_
>>> requirements for marking extensions as stable, so that production code
>>> will inevitably have to use non-stable extensions, and not much is
>>> gained.
>>
>> This, too, is exactly what I was thinking. Industrial users and book authors have the most to gain from an extension being marked as stable. I would expect that proposals would come from these groups marking extensions as stable, and then we could have a debate.
>>
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- 
Chris Allen
Currently working on http://haskellbook.com