<div dir="ltr"><div dir="ltr">On Wed, 9 Dec 2020 at 18:48, Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Dec 9, 2020, at 6:17 AM, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>
>  Or would you rather see these stay in their standalone extensions forever? (which I would find, personally, rather alarming)<br>
<br>
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.<br></blockquote><div><br></div><div>So let me separate the two points here:<br></div><div><ul><li>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)<br></li><li>Whether advanced features like TypeFamilies and GADTs should need to be explicitly enabled. I disagree with this:<br></li></ul></div><div><ol><ol><li>To a large degree these features already <b>are</b> 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.<br></li><li>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.</li></ol></ol><div>Having said all this, there definitely <b>are</b> cases where you might want to <b>disable </b>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.<br></div><div><br></div><div>Cheers</div><div>Simon<br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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`?)<br>
<br>
> 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.<br>
<br>
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.<br>
<br>
Richard<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div>