<div dir="ltr"><div>Hello,</div><div><br></div><div>I don't have a strong feeling about `MonoLocalBinds`, I could take it or leave it, even though it disables some Haskell'98 programs.</div><div><br></div><div>However the "fancy types" situation is different:</div><div><br></div><div>   1. I don't see "FancyTypes" as being fork-like, but rather as simply being an extension in the traditional GHC sense.   This is more modular, and is in the spirit to the multiple languages of Dr. Racket.  I see GHC's ability to control what extensions are on as a strength not a weakness---in my mind GHC 2021 just helps control the extensions at a slightly coarser granularity.</div><div><br></div><div>   2. I am indeed not convinced that these extensions are in their "final" form, even though they are useful at the moment,   I am thinking of things like:</div><div><br></div><div>   * many people dislike the aspect of GADTs where the declared parameters don't really bind anything, and writing records in that notation is quite clunky, it is still rather hard to explain when one needs to write a type signature when matching on a GADT.</div><div><br></div><div>   * for many use cases (the majority in my experience) `DataKinds` does not work the way I'd want it to, as typically you only want to define types of a new kind, and there is no need to pollute the value level with unused constructors---we have an accepted proposal about this, but it was never implemented, as I'd probably have to implement it, and I don't have the time to do it.   There is also the unfortunate backtick situation, etc.</div><div><br></div><div>   * type families have dark semantic corners (e.g., things like `Any` which may refer to inhabitants of empty types), and also have numerous extensions/variants (e.g., dependent parameters, partial applications), so I'd rather turn them on by default when they stop growing.  Also I imagine DH has opinions on how one should write "type" functions.</div><div><br></div><div>-Iavor</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 1:11 AM Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I would like to push back here: this seems to be suggesting a fork-like situation, where we have two kinds of Haskell (fancy and non-fancy). I do feel quite strongly that we should be converging on a single language rather than creating splits. Or perhaps the suggestion is that we don't want these extensions on by default *yet*?<br></div><div><br></div><div>Responding to Iavor's point:</div><div><br></div><div>> I think these extensions convey useful information about the mindset you
 should use when working with a specific code base, which is quite 
different from working with ordinary Haskell.</div><div><br></div><div>I personally have been working with these extensions enabled for all my code for a long time now. I'm by no means a heavy user of "fancy types", I make occasional use of type families and GADTs to solve specific problems when they arise. But I'm not even sure what this "different mindset" is - I certainly don't feel like I have to think differently. Of course it's entirely possible that I'm just an unsophisticated user and if I understood how to think about the type system with these extensions my life would be better!</div><div><br></div><div>The one exception that does trip me up is MonoLocalBinds, I often have to supply a type signature when intuitively I didn't think I needed one.<br></div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 8 Dec 2020 at 19:57, Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I agree with this. Fancy types are, well, fancy, and users should have to boldly declare that they're trying to be fancy.<br>
<br>
Richard<br>
<br>
> On Dec 8, 2020, at 11:46 AM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>> wrote:<br>
> <br>
> Hello,<br>
> <br>
> I would like to advocate that things like `DataKinds`, `TypeFamilies`, and `GADTs` are not enabled by default in GHC2021.     The reason I ask for this is that unlike many others, I think these extensions convey useful information about the mindset you should use when working with a specific code base, which is quite different from working with ordinary Haskell.<br>
> <br>
> I do think it would be quite reasonable to have an umbrella extensions for FancyTypes too, which would enable all of those, I just don't think they should be enabled for every Haskell program.<br>
> <br>
> -Iavor<br>
> <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>
<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>
</blockquote></div></div>