[ghc-steering-committee] A few more pleas

[Simon Marlow]

On Wed, 9 Dec 2020 at 18:48, Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> > On Dec 9, 2020, at 6:17 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
> >  Or would you rather see these stay in their standalone extensions
> forever? (which I would find, personally, rather alarming)
>
> I'm attacking from the standpoint that these will be extensions forever --
> or, at least until we have a specification of them. (Amazingly, we don't
> have a specification for either one, right now.) Haskell will always have
> new learners, and I think it's reasonable to guard some advanced features
> behind extensions, always. Perhaps we need to simplify the space of
> extensions (including a FancyTypes or DependentTypes extension), but I'd be
> happy to see these features guarded into perpetuity.
>

So let me separate the two points here:

   - Extensions without a specification shouldn't be part of the default
   language. I'd agree that they certainly shouldn't be part of the Haskell
   *standard*, but the bar for a GHC extension, even one that is enabled by
   default, is lower than this I think. (Indeed, one might point out that
   there wasn't a proper specification of the Haskell type system when the
   standard was published)
   - Whether advanced features like TypeFamilies and GADTs should need to
   be explicitly enabled. I disagree with this:


   1. To a large degree these features already *are* guarded in the sense
      that you have to explicitly define a type family or a GADT.
Having to jump
      through the extra hoop of adding a LANGUAGE pragma is
unnecessary friction.
      Yes there are exceptions to this - needing a LANGUAGE pragma to
      pattern-match on a GADT for example - I also think this is unnecessary
      friction, because you can understand what the pattern-match does
by looking
      at the definition of the type. Incidentally you don't need {-# LANGUAGE
      TypeFamilies #-} to use a type family in a type, so we're not very
      consistent here.
      2. I don't think the extra signal of a LANGUAGE pragma or a flag in
      the Cabal file really adds anything useful for extensions that
are largely
      stable. As a user you don't go looking for these things when reading code
      so that you can understand what dialect the code is written in, we just
      read code. There needs to be a common dialect as far as possible.

Having said all this, there definitely *are* cases where you might
want to *disable
*fancy type features. At FB we have a large codebase of DSL code that is
used by engineers with a wide range of Haskell experience, so we want to
keep the level of fancy-types to a minimum. This is like the "beginner
Haskell" use case where we want to be able to turn off a lot of advanced
features to flatten the learning curve. This is an important use case that
GHC should continue to support by having a way to turn off extensions, but
I don't think it means that the default mode should also have these
extensions disabled.

Cheers
Simon


>
> About specification: The OutsideIn paper includes an overly-generous
> specification of GADTs, but not a precise one. I am unaware of a precise
> specification of what programs are accepted with GADTs, beyond the GHC
> implementation. Along similar lines, there is no specification of how type
> families reduce. (For example, what happens with `type family F where F =
> If True Int F`?)
>
> > How is a partial type signature a partially-written program? Does the
> absence of type signature on a binding make a program partially written?
> Because a partial type signature is more than no signature at all, so it
> should be considered less partial at least.
>
> This is a good point. I see partial type signatures as a development tool,
> where a user elides part of a type signature in order to get the compiler
> to provide information on how to fill it in. But maybe that's not the best
> viewpoint.
>
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201210/54e03840/attachment.html>