[ghc-steering-committee] #536: Type-level literals as a separate language extension, rec: accept

[Joachim Breitner]

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 at joachim-breitner.de
  http://www.joachim-breitner.de/