Patch 2409 Switch from * to Type (and 1 more)

Title Switch from * to Type (and 1 more)
Superseder Nosy List ganesh
Related Issues
Status accepted-pending-tests Assigned To

Created on 2024-06-07.08:04:56 by ganesh, last changed 2024-06-21.19:48:47 by bfrk.

File name Status Uploaded Type Edit Remove
patch-preview.txt dead ganesh, 2024-06-07.08:04:55 text/x-darcs-patch
patch-preview.txt ganesh, 2024-06-17.00:10:56 text/x-darcs-patch
switch-from-_-to-type.dpatch dead ganesh, 2024-06-07.08:04:55 application/x-darcs-patch
switch-from-_-to-type.dpatch ganesh, 2024-06-17.00:10:56 application/x-darcs-patch
See mailing list archives for discussion on individual patches.
msg23982 (view) Author: ganesh Date: 2024-06-07.08:04:55
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
msg23988 (view) Author: ganesh Date: 2024-06-08.18:18:32
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:


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.
msg24012 (view) Author: bfrk Date: 2024-06-15.19:15:43
> 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?
msg24013 (view) Author: ganesh Date: 2024-06-15.19:17:40
> 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.
msg24014 (view) Author: bfrk Date: 2024-06-15.19:41:48
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.
msg24017 (view) Author: ganesh Date: 2024-06-17.00:10:56
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
msg24018 (view) Author: ganesh Date: 2024-06-17.00:11:18
I'll screen this one if you're ok with it.
msg24022 (view) Author: bfrk Date: 2024-06-17.21:07:13
Go ahead. After reading some of the proposal I am (grudgingly) accepting 
that using * for Type is getting in the way of language evolution.
msg24031 (view) Author: bfrk Date: 2024-06-21.19:48:46
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.
Date User Action Args
2024-06-07 08:04:56ganeshcreate
2024-06-08 18:18:34ganeshsetstatus: needs-screening -> in-discussion
messages: + msg23988
2024-06-15 19:15:43bfrksetmessages: + msg24012
2024-06-15 19:17:40ganeshsetmessages: + msg24013
2024-06-15 19:41:48bfrksetmessages: + msg24014
2024-06-17 00:10:56ganeshsetfiles: + patch-preview.txt, switch-from-_-to-type.dpatch
messages: + msg24017
2024-06-17 00:11:18ganeshsetstatus: in-discussion -> needs-screening
messages: + msg24018
2024-06-17 21:07:14bfrksetmessages: + msg24022
2024-06-18 00:12:08ganeshsetstatus: needs-screening -> needs-review
2024-06-21 19:48:47bfrksetstatus: needs-review -> accepted-pending-tests
messages: + msg24031