Data.List should re-export GHC.List.List

[Kleidukos]

Proposal

Data.List should re-export GHC.List.List

It is terribly awkward to have

import Data.List qualified as List
import GHC.List (List)

Impact Assessment

I'll fill out this part when I am able to compile the ghc-9.4.4 branch of GHC, for the moment I'm facing hardships with "missing dependencies".

[treeowl]

I don't understand what makes this awkward. Also, when do you need List?

[Kleidukos]

Well, for once, awkwardness levels are influenced by how arm-twisting it is. Today we have the following places for List-related things:

• Data.List
• GHC.List
• GHC.OldList

The first one is the official entry point for List operations in the base library.
The last two are internal modules for GHC, which should not be accessed directly.

Moreover it is highly uncommon to have such a primordial type defined in an internal module, have its operations re-exported in a public-facing module, but not the type itself.

Hence this proposal to solve a very odd mismatch between GHC.List and Data.List

Also, when do you need List?

When I'm writing a tutorial for beginners and have no desire to showcase the inconsistency of our user experience.

[treeowl]

You haven't yet explained the purpose of importing List at all, which everything else must lean on.

[Kleidukos]

When one imports a type it is usually to use it in a type signature.

[mixphix]

FWIW, I'm in favour of exporting this name from Data.List. I don't foresee many clashes, other than perhaps type synonyms that would then be obsoleted. Some further justification:

• Many modules are designed with overlapping names, to aid the programmer's memory.

  import Data.List qualified as List (uncons, (\\), ...)
  import Data.Map qualified as Map (fromList, (\\), ...)
  import Data.Set qualified as Set (fromList, (\\), ...)
  import Data.Text qualified as Text (uncons, ...)
  import Data.Vector qualified as Vector (fromList, uncons, ...)

• Many of these modules are named after their type, which is usually imported unqualified:

  -- import Data.List (List)
  import Data.Map (Map)
  import Data.Set (Set)
  import Data.Text (Text)
  import Data.Vector (Vector)

• The lack of a bona fide prefix name for the type former [] is a historical mistake that has only increased the complexity of parsers, and creates a syntactic anomaly at a level where a new programmer is still being introduced to the language. It's a linked list -- it's incredibly simple and useful, but it's not magic!
• Here are some examples of how the current syntax -- "punning" between value- and type-level -- can lead to confusion for newcomers.

[phadej]

Isn't this a moral duplicate of #22. i.e. the plan is accepted, but someone needs to write the patches to aid monomorphisation migration of Data.List.

[mixphix]

I truly don’t understand how this could possibly be interpreted as having anything to do with monomorphization.

[dixonary]

As a relative outsider who is also regularly using List - including in a new learners context - this is an objectively sensible change and I support it without reservation.

It does not appear to be a duplicate (moral or otherwise) of #22 except in that it also concerns lists.

[ocharles]

@phadej perhaps you read this issues as Data.List should re-export GHC.List (the module), while this issue is really about Data.List should re-export GHC.List.List (the type).

[tomjaguarpaw]

To attempt to fill in some blanks (and I didn't know about this until I just looked), it appears that base-4.18.0.0 added data List a which is another way of saying [a]. base-4.17.1.0 didn't have it.

List can be preferable to [] in some ways, for example

• Avoiding type/term punning
• Avoiding privileged syntax

(I don't know what the relative status of [] and List is. I think they are/it is (a) built-in definition(s) but I don't know if one of them counts as a synonym for the other.)

[jappeace]

This is a good idea, you've my support. :)

[chshersh]

This CLC issue looks relevant:

• base API changes introduced by GHC proposal 475 #162

I don't like inconsistency. And I'd pretty weirded out by having List easily accessible in base while Tuple doesn't have the same status, even though the existence of both types pursues the same goal (in my understanding).

So my preference is to have the same decision on both of this issues (162 and 182).

[mixphix]

It is no doubt a source of frustration to potential proposers that the outcome of their proposal should depend on the outcomes of other, tangentially-related proposals, for the sake of consistency, rather than accepting the specific incremental changes a proposer puts forth (and declares that they have the bandwidth to pursue). The "inconsistency" may spur another member of the community to do that work for you anyway, after all!

[chshersh]

@mixphix To clarify, I didn't ask the author of this proposal to do more work neither my intention was to block their work by the outcome of another proposal.

It was a non-binding ask to other CLC members to vote the same on both proposals (in any order of vote).

[phadej]

@ocharles I see. thanks.

In #29 CLC argued that "GHC" stuff could as well be exported just from GHC.List. I don't think that GHC proposal 475 will affect ordinary user just yet.

Btw, was there a CLC proposal to add data List to GHC.List in the first place?