On Wed, 9 Dec 2020 at 10:20, Simon Peyton Jones <simonpj@microsoft.com> 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 <ghc-steering-committee-bounces@haskell.org> On Behalf Of Simon Marlow
Sent: 09 December 2020 09:11
To: Richard Eisenberg <rae@richarde.dev>
Cc: ghc-steering-committee <ghc-steering-committee@haskell.org>
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 <rae@richarde.dev> 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 <iavor.diatchki@gmail.com> 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