For this first round, I want us to focus on the categorisation of
language extensions as proposed by Richard and Simon M (sections 2.1
and 2.3, respectively, of our draft notes). As I feel that we will
need to have these categories identified in order to discuss the later
points.
Here are the categories that are common to both (consult the document
for more details):
1. Extensions that are either in GHC20xx or could be part of a future
GHC20xx (e.g. GADTs)
2. Experimental language features (e.g. LinearTypes)
3. Extensions that allow module-wide violation of some general
principle that holds elsewhere (e.g. OverlappingInstances)
4. Extensions that allow access to deprecated features (e.g. DatatypeContexts)
5. Extensions that should be compiler flags, which do not actually
change the accepted language (e.g. Safe)
Just to expand on the rationale here: the categories I proposed (1-5 + 7) are intended to be *exclusive*: each extension belongs to exactly one of them. The idea is to give us a way to explain to people why an extension is or is not part of GHC20xx.
We can have more ways to categorise extensions if we want (e.g. syntactic vs. not syntactic), and indeed that might be useful. But this one (1-5 + 7) seemed to me to be most helpful towards the goal of adding some clarity to the GHC20xx process.
Q1: Are all the categories 1–5 relevant? If you would like to remove
some categories, which and why (free form)?
Yes
Q2: Is category 6 relevant?
Q2.Y: If you found category 6 to be relevant: should it be its own
category, or should it be a subcategory of 1?
Whether an extension is syntactic or not is a useful thing to know, but it doesn't belong alongside 1-5,7
because it's not an exclusive category. Let's keep it separate.
Note that extensions that add syntax can still often break existing
programs, either because they steal keywords or they give new meaning to
existing syntax. I'm too lazy to search for examples but there are very
probably syntactic extensions that really do change the meaning of an
existing correct program, rather than just cause an existing program to
be rejected. So an extension being syntactic doesn't necessarily make it a free addition to GHC20xx although it probably does mean it's less risky.
Q2.N: If you found category 6 not to be relevant, in which category
would you classify OverloadedStrings? What about PolyKinds?
OverloadedStrings: 1
PolyKinds: 1 or 2
Q3: Is category 7 relevant?
Maybe :) It might be possible to put those extensions into 1 if we can convince ourselves the breakage potential is low enough. It does seem sensible to have a category for extensions that are mature but so specialised that we don't plan to include them in GHC20xx. That's different from 2 (experimental) because we expect those to eventually mature and move to 1 (or 7, if we keep it).
Q3.Y: If you found category 7 to be relevant: should it be its own
category or should it be a subcategory of 5?
I don't understand how 7 makes sense as a subcategory of 5
Q3.N: If you found category 7 not to be relevant: in which category
would you classify MagicHash? What about UnboxedTuples?
Q4: In which category would you classify Strict?
5
Q5: Is there any category that you feel is missing from the list? If
so, please argue (free form).
Cheers
Simon
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee