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*? Responding to Iavor's point:

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.

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! 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. Cheers Simon On Tue, 8 Dec 2020 at 19:57, Richard Eisenberg wrote:

I agree with this. Fancy types are, well, fancy, and users should have to boldly declare that they're trying to be fancy.

Richard

...

On Dec 8, 2020, at 11:46 AM, Iavor Diatchki wrote:

Hello,

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.

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.

-Iavor

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Wed, 9 Dec 2020 at 10:20, Simon Peyton Jones wrote:

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.

I’d like to train Haskell users to get used to MonoLocalBinds. I simply don’t know a way to give reliable, predictable *type generalisation* (to get polymorphic types) for local bindings, in the presence of GADTs etc. I don’t think that situation is going to improve (i.e. it’s not a short term problem) … indeed it may become more pressing as the type system advances. It’s switched on by TypeFamilies, and I think GADTs, so many of us are using it anyway.

Most local bindings are not polymorphic, so no problem; those that are probably deserve a type signature anyway. But I accept that there is a cost here: we’re giving up on generalisation for local bindings.

So if we are thinking about the long term future of the language, I think MonoLocalBinds will be a part of it.

Sure, if MonoLocalBinds is the price of TypeFamilies+GADTs, I'll pay it. But I have not succeeded in training myself to get used to it. I could be too old to be retrained though :) Cheers Simon

Simon

*From:* ghc-steering-committee *On Behalf Of *Simon Marlow *Sent:* 09 December 2020 09:11 *To:* Richard Eisenberg *Cc:* ghc-steering-committee *Subject:* Re: [ghc-steering-committee] A plea against "fancy types" in GHC2021

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*?

Responding to Iavor's point:

...

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.

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!

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.

Cheers

Simon

On Tue, 8 Dec 2020 at 19:57, Richard Eisenberg wrote:

I agree with this. Fancy types are, well, fancy, and users should have to boldly declare that they're trying to be fancy.

Richard

...

On Dec 8, 2020, at 11:46 AM, Iavor Diatchki wrote:

Hello,

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.

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.

-Iavor

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C8a4c930c75a24f5e457b08d89c227484%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637431019081096090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEQuslTRzMD7bfoiXhfKX7VpiP8AmEZp6F7Xp1ur0qI%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C8a4c930c75a24f5e457b08d89c227484%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637431019081096090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EEQuslTRzMD7bfoiXhfKX7VpiP8AmEZp6F7Xp1ur0qI%3D&reserved=0

Hello, I don't have a strong feeling about `MonoLocalBinds`, I could take it or leave it, even though it disables some Haskell'98 programs. However the "fancy types" situation is different: 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. 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: * 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. * 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. * 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. -Iavor On Wed, Dec 9, 2020 at 1:11 AM Simon Marlow wrote:

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*?

Responding to Iavor's point:

...

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.

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!

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.

Cheers Simon

On Tue, 8 Dec 2020 at 19:57, Richard Eisenberg wrote:

...

I agree with this. Fancy types are, well, fancy, and users should have to boldly declare that they're trying to be fancy.

Richard

...

On Dec 8, 2020, at 11:46 AM, Iavor Diatchki wrote:

Hello,

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.

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.

-Iavor

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee