Hello, Am Mittwoch, dem 08.03.2023 um 10:57 +0000 schrieb Simon Peyton Jones:
Unless I am missing the point, I can’t really make an informed decision before we have concluded our policy discussion, in particular, on whether we want to go towards a future where everyone is welcome to turn extensions on and off to build their little fine-grained preferred language islands, or whether that is something we want to avoid and use extensions only as stepping stones towards a ((eventually) single) future Haskell, at the cost of having to tell some people that they can’t expect that every possible dialect of Haskell will be supported.
I don't think these two are incompatible. Even if we have a "single future Haskell" in mind, it's fair enough for people to switch things on and off if they want. Offering flexiblity at low cost seems OK to me; other things being equal, it's not for us to say what they should or should not want. (If the implementation or maintenance cost was high I might think again, but I don't think it is in this case.)
It is certainly a reasonable policy that we _want_ GHC Haskell to be highly customizable, and that users should be able to use language extensions to tailor the language to their needs and preferences. (So maybe we’d add UnqualifiedImports so that PVP-adherence can be enforced with -XNoUnqualifiedImports, and we’d add ASCIISyntax, so that fans of unicode can add -XNoASCIISyntax and get to use `forall` and `->` as variable names, since ∀ and → are the keywords now… – just building up a little strawmany army here…) But its also reasonable to say that, as convenient as it is for the individual developer asking for the feature, it’s not actualy good for the ecosystem as a whole. And this is not just about the implementation cost: It’s the cost of yet another language extension that people dealing with more than just their own code have to understand, to decide whether they want to use it, to worry about whether it’s on or off when reading code and (in this case) mentally resolving name. Choice is good for those who want the alternative, but incurs a (small, but relevant) cost on everyone! I see appeal in either policy, but they do seem rather incompatible to me, and I hope the general policy discussion will give us better guidelines here. More concretely about this proposal: It seems that one motivation is that DataKinds is “bad” in some way, namely in that term constructors are available in types. So if we accept this proposal, does that mean we agree with that assessment, what are we going to do about it? Is there a better way of referring to term constructors that we could work to wards to that works for everyone? Or are we going to have multiple future Haskell dialects, one with strict separation between terms and types, one with some things also on the type level (basic literals, but no tuples or user-defined constructors), and a third one that’s the full story? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/