[ghc-steering-committee] A plea against "fancy types" in GHC2021

[Simon Marlow]

On Wed, 9 Dec 2020 at 10:20, Simon Peyton Jones <simonpj at 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 at haskell.org>
> *On Behalf Of *Simon Marlow
> *Sent:* 09 December 2020 09:11
> *To:* Richard Eisenberg <rae at richarde.dev>
> *Cc:* ghc-steering-committee <ghc-steering-committee at 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 at 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 at 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 at 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 at 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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/368df114/attachment-0001.html>