Reviewing our global warning suppressions.

Fixed one of them, added a comment about the other to stop
me looking again in future.

Note: I did consider exposing Data.Kind ( Type ) via Darcs.Prelude
but I don't think there's any version of GHC where it comes from
the Prelude so decided not to.

2 patches for repository darcs-unstable@darcs.net:/opt/darcs/screened:

patch d7bd62bf7e14c96184ab465f3f2af05f9676b00b
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Jun  7 07:59:52 BST 2024
  * Switch from * to Type

patch 46b00d57a68659014ccb72c4702da3fc501a5a65
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Jun  7 09:00:16 BST 2024
  * add a comment about why we have NoMonoLocalBinds etc

Attachments

• patch-preview.txt
• switch-from-_-to-type.dpatch

Moving to in-discussion for now.

> Just one remark here: "* -> Type" is not something I am keen on,
> I would rather blanket suppress any warnings about this.

I'm not a huge fan of it either, but my understanding is that it
will be forced on us within the next couple of years:

https://github.com/ghc-proposals/ghc-
proposals/blob/master/proposals/0143-remove-star-kind.rst#proposed-
change-specification

If that timeline is followed it'll be deprecated in August 2025
and potentially removed from February 2027.

So we can either hold out till the last possible minute, or just get
on with it now-ish. I don't feel that strongly.

> But, if you insist on it, *please* export it from Darcs.Prelude. The 
> only reason not to export standard basic items we use in many
> places (e.g. things like void, when, and unless from Control.Monad)
> is that it would require lots of changes in imports. But this is a
> new name and in that case it's the other way around.

Personally I'm not all that keen on effectively developing a custom 
Prelude, but I can live with it if you're strongly in favour.

> Personally I'm not all that keen on effectively developing a custom 
> Prelude, but I can live with it if you're strongly in favour.

There are certainly pros and cons. I am not /strongly/ in favour of a custom 
Prelude that exports a lot more names than the standard one (though there are 
some good arguments, see below). However, we already do have Darcs.Prelude and 
making use of it in situations like this (i.e. to ease the * -> Type 
migration) is not really a policy change; so I /am/ strongly in favour of 
exporting 'Type' from Darcs.Prelude.

Regarding a more general custom Prelude, it would solve two issues for me: 
first, having to add trivial imports, as well as having to remove them if they 
are no longer used (because of warnings), is a constant annoyance; second, 
these trivial imports lead to unnecessary conflicts with unpublished work, of 
which I tend to have quite a lot. So I wouldn't mind to have much of 
Data.List, Data.Maybe, Control.Monad+Applicative, and probably some more 
available from Darcs.Prelude. We may have to occasionally hide some names 
there if new additions cause trouble (or add other kinds of work-arounds), but 
that's a lot less maintenance work than what we have now, and it's 
concentrated in one module instead of being spread all over the place.

What are the disadvantages in your view?

> What are the disadvantages in your view?

Mainly that it makes the codebase a bit harder to understand for someone
with general Haskell experience. It's probably not a big deal compared
to the rather bigger complexities of the codebase though.

I can think of a more serious potential problem. What if, in certain 
places, we want to use generalized concepts (Foldable comes to mind) that 
collide with e.g. names in Data.List? It would be bad if we'd have to 
start hiding names from our own Prelude... oh, we already do that, in no 
less than 15 modules. Hmmmm.

updated version that exports Type from Darcs.Prelude

1 patch for repository darcs-unstable@darcs.net:/opt/darcs/screened:

patch bfbeb042f381f0a7ef1c81266ac193e408d5314b
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Mon Jun 17 01:07:41 BST 2024
  * Switch from * to Type

Attachments

• patch-preview.txt
• switch-from-_-to-type.dpatch

I'll screen this one if you're ok with it.

Go ahead. After reading some of the proposal I am (grudgingly) accepting 
that using * for Type is getting in the way of language evolution.

Fine. I think this is a good compromise: we are future proof on the one 
hand and reduce the churn as much as possible on the other.