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

[Iavor Diatchki]

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 <marlowsd at gmail.com> 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 <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
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/11d8ccdf/attachment.html>