On Fri, 17 Feb 2023 at 14:07, Arnaud Spiwack
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
Best, Arnaud _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee