Amend 475 to use ghc-experimental for exports #603

tek · 2023-07-11T17:03:58Z

Motivated by recent conversations with the CLC about stability of the API of base, we devised the plan to introduce a new package, ghc-experimental, that shall become the initial home for exports of new entities that should be tried out by the community before committing to a stable API.

This amendment changes the modules exporting the new tuple- and sum-related entities to use that new package.

I'd appreciate feedback, in particular about whether the creation of this package should be part of the proposal or be handled separately, and whether the deprecation of ghc-prim:GHC.Tuple for the rename to GHC.Internal.Tuple should be included here.

simonpj · 2023-07-11T21:49:30Z

Looks good to me.

int-index · 2023-07-11T21:51:56Z

proposals/0475-tuple-syntax.rst

   many *unsafe* internals.

   This proposal lists several definitions to be exported from ``GHC.Prelude``, but leaves other
   definitions to be added in separate proposal(s).

+   ``GHC.Tuple`` will clash with the same module from ``ghc-prim``.


Can we avoid the clashes? Nothing compels us to create a conflicting GHC.Tuple in ghc-experimental, at least not for the sake of this proposal. Just leave it in ghc-prim?

The new GHC.Sum and GHC.Prelude can go to ghc-experimental, of course, as there is no conflict.

Can we avoid the clashes? Nothing compels us to create a conflicting GHC.Tuple in ghc-experimental, at least not for the sake of this proposal. Just leave it in ghc-prim?

Good qn. But if we leave it in ghc-prim then clients of the new tuple stuff will be force to depend on ghc-prim which we do not want. Rather, I think we should transition ghc-prim:GHC.Tuple to become ghc-prim:GHC.Internals.Tuple. Quite how fast we do that isn't clear to me.

@goldfirere ?

our new GHC.Tuple depends on base (it needs TypeNats and possibly TypeError), so leaving it in ghc-prim is a no-go.

now that the module naming scheme is clear, GHC.Tuple can stay in ghc-prim!

int-index · 2023-07-11T21:56:07Z

proposals/0475-tuple-syntax.rst

-   peculiar to GHC that are safe to use in ordinary code.
-   This module is *not* intended as a replacement to ``Prelude``,
-   but instead a complement to it. This module is a counterpart to ``GHC.Exts``, which exports
+1. Create three new modules in ``ghc-experimental`` called ``GHC.Prelude``,


GHC.Prelude is actually taken by the GHC API for the custom Prelude used by GHC itself. Are we absolutely sure we want to repurpose this name, when we could simply pick a different one? Need opinion from @goldfirere

Huh -- that is annoying.

It demonstrates that we are using the module prefix "GHC." in two different ways:

Modules of GHC itself (e.g. GHC.Core.Opt.Simplify)

Modules in ghc-experimental.
These are not the same purpose.

Maybe ghc-experimental should start with GHCX.? Thus GHCX.Prelude, GHCX.Tuple. Or some other prefix?

GHCX.* is just a slightly different take on GHC.Exts.* that @tek previously suggested, right? I believe GHC.Exts.* is good and descriptive. For example, GHC.Exts.Tuple is "GHC's extensions to tuples". When those get stabilized, they can be reexported from Data.Tuple (with CLC's approval)

I wonder about the broader situation here - would the idea be that all GHC.Exts.* modules/names end up in non-GHC.Exts.* modules if/when brought into base? Since if anything is added to base also under the GHC.Exts.* moniker, you would still end up with a naming conflict during the deprecation period from ghc-experimental (edit: actually I suppose there might not be a deprecation period if it's just reexported from base, and stays in ghc-experimental, but that doesn't affect my question I think)

GHC.Exts exposes some unsafe operations, as in "crash the process" unsafe, which the original text uses as contrast for the purpose of GHC.Prelude…would calling the new namespace GHC.Exts.* associate ghc-experimental with that notion?

On the other hand, GHC.Exts might be a candidate for migration to ghc-internals.

There is also a large number of GHC.* modules in base that might be a source for additional conflicts later.

I find the prefix GHC. for things in ghc-experimental strange, as they are neither about GHC (e.g. a plugins) or part of GHC (e.g. GHC.Prelude). It's as if I start to prefix my library modules with Nomeata.. I expect developers to find this naming confusing (me already included.)

How about we append Experimental to the module name from base where things might end up in? Data.Tuple.Experimental?

The only thing is should GHC's experiments have a monopoly on such names?

Data.Tuple.GlasgowExperiment lol

What it is comes first, "compilation" is not relevant and thus unmentioned, who experiment and so not to conflict with other experiments comes last.

now called Prelude.Experimental.

simonpj · 2023-07-13T13:30:11Z

How about we append Experimental to the module name from base where things might end up in? Data.Tuple.Experimental?

Or prefix it, so that ghc-experimental modules are in the Experimental.* name space. Thus Experimental.Data.Tuple.

(I can't speak for others but I'm quite open to renaming the library itself too, incidentally, but just experimental sounds a bit too generic.)

numlit2 · 2023-07-13T19:58:12Z

Or prefix it, so that ghc-experimental modules are in the Experimental.* name space. Thus Experimental.Data.Tuple.

Experimental.* is very good. I know I will import something unstable. GHC.Exts.*doesn't tell me anything.

adamgundry · 2023-08-03T20:24:07Z

This somewhat overlaps with the discussion at haskellfoundation/tech-proposals#53.

I would suggest we use Prelude.Experimental, Data.Tuple.Experimental and Data.Sum.Experimental. Moreover we could have Prelude.Experimental export Type (cf. haskell/core-libraries-committee#193).

tek · 2023-08-03T21:34:10Z

That seems like a reasonable schema to me, and it saves us the discussion about GHC.Prelude.

But exporting Type from there sounds like it would become its permanent home – the problem articulated in the other discussion isn't that Type isn't available in base, but that it isn't implicitly in scope, no?

adamgundry · 2023-08-04T07:14:03Z

the problem articulated in the other discussion isn't that Type isn't available in base, but that it isn't implicitly in scope, no?

Indeed, so the benefits are limited. I was just thinking about what else Prelude.Experimental could reasonably export, as a "staging ground" for things that may be added to Prelude later. It's fine if you prefer to leave that discussion for a separate proposal.

tek · 2023-08-25T15:59:23Z

MR now reflects these changes: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8820/diffs?commit_id=9be5e1645df92e217a2ce5f806940cba016277f7

tek · 2023-08-29T13:42:32Z

@nomeata would you submit, please?

nomeata · 2023-08-29T16:43:51Z

I am not sure if this needs the full committee process. Isn’t it the only reasonable choice given the (accepted) plan around the use of ghc-experimental?

If @simonpj or @adamgundry could sanity-check the diff I’m inclined to just merge as it.

adamgundry

Thank you for pushing this on @tek! I have a few minor nitpicks but I agree that a full committee review seems unnecessary given that most of this is essentially predetermined.

I'm wondering whether it helps or hinders to give all the fully-qualified module names referring to modules in ghc-prim. Arguably, where things live in ghc-prim/ghc-internals are implementation details that needn't be part of the specification, provided we are clear about what is being exposed from base (nothing?) and ghc-experimental. But I'll leave this up to your preference.

adamgundry · 2023-08-29T19:23:17Z

proposals/0475-tuple-syntax.rst

-   the definitions below in ``GHC.Tuple`` on ``GHC.TypeLits``.) ::
+#. Export the following definitions from ``Data.Tuple.Experimental`` and
+   ``Prelude.Experimental``. (Implementation note: These would probably end up
+   in a new module ``Data.Tuple.Prim``, due to the dependency from


Was this renaming intended? Further down the proposal still refers to GHC.Tuple.Prim. Given the name I assume this would be a new module in ghc-prim, but it wouldn't hurt to be explicit. It's not obvious to me why we need all of GHC.Prim, GHC.Tuple and GHC.Tuple.Prim, but those are implementation details that aren't essential to the specification anyway.

Suggested change

in a new module ``Data.Tuple.Prim``, due to the dependency from

in a new module ``GHC.Tuple.Prim``, due to the dependency from

ah, now that we use Data.Tuple.Experimental instead of GHC.Tuple (which was supposed to move to base), we could probably use the latter for the new definitions instead of GHC.Tuple.Prim. I'll change that and see if it creates any issues.

ah, but GHC.Tuple.Prim is already in master due to an older MR that implements only a small part of the proposal – should we discard it anyway and break the API of ghc-prim?

@adamgundry what do you think?

I think ghc-prim has no stability guarantees, so you should feel free to remove GHC.Tuple.Prim unless there is some implementation reason to keep it.

adamgundry · 2023-08-29T19:23:43Z

proposals/0475-tuple-syntax.rst

      where there are *n-1* commas.

-   #. An occurrence of ``GHC.Exts.Unit#`` is pretty-printed as ``(# #)``.
+   #. An occurrence of ``GHC.Types.Unit#`` is pretty-printed as ``(# #)``.


We seemingly have GHC.Types.Unit# here, but GHC.Exts.Unit# elsewhere, and when Unit# is introduced it says it "would likely be exported from GHC.Prim originally". (And similarly for the other types.)

those should all have been changed to GHC.Types, I overlooked a few occurrences.
GHC.Prim is a virtual module, so my assumption is that Richard hadn't determined the precise module yet at the point of writing it.

The straightforward change would have been to use Data.Tuple.Experimental instead of GHC.Exts – I used GHC.Types because I now know what we landed on eventually…do you think that's too much retconning? We could also change the other sentence to say "would likely be exported from GHC.Types originally".

ah no, there's no equivalent of GHC.Exts with the new schema…

proposals/0475-tuple-syntax.rst

Co-authored-by: Adam Gundry <[email protected]>

simonpj · 2023-08-29T21:01:26Z

Please could the propsal say clearly

What are the changes to the API of base?
What are the changes to the API of ghc-experimental?
What other changes to ghc-internal packages are there? E.g. to the union of ghc-internal and ghc-prim? True, this doesn't need to be part of the specification, since it's an implementation matter, and it should be explained as such.

Currently all these changes are mixed together, and only module names are given, not packages, so I can't work out the answer. Could you simply summarise in one place?

I think there is quite a bit of (1) changes, and they need agreement from CLC. E.g. changes to GHC.List.

I notice mention of GHC.Tuple.Prim. What package is that in? And I thought we'd agreed that ghc-internal modules would usually look like GHC.Internal.Tuple?

adamgundry · 2023-08-30T12:57:09Z

I think there is quite a bit of (1) changes, and they need agreement from CLC. E.g. changes to GHC.List.

Good point. I was assuming there would be no base changes, which I think would be the case if point 10 was adapted so that GHC.List would not re-export List? (And the references to GHC.List.List changed to GHC.Types.List.)

EDIT: actually, I realise now that GHC.List already exports List; and indeed there is a proposal to have Data.List do so (haskell/core-libraries-committee#182).

simonpj · 2023-08-31T07:46:55Z

I think that, more than just edinting point 10, it would help the reader a lot if there was a brief summy of

Changes to ghc-experimental
Changes to base

The existing structure is fine; just a summary is needed so that the reader can quickly get that overview.

tek · 2023-08-31T14:28:11Z

I used the libraries section we added to the template last week. Other than List, there's no change to base.

adamgundry

Apart from a couple of RST syntax nits this looks good to me, thanks @tek!

@simonpj are you happy with the revised state? AFAICS there is no need for further CLC consultation as the only change to base is the export of List from GHC.List, which has already been implemented.

adamgundry · 2023-09-13T07:25:05Z

proposals/0475-tuple-syntax.rst

-#. Export the following definitions from ``GHC.Exts`` and ``GHC.Prelude``. These replace
-   the existing tuple definitions (in ``GHC.Classes``) today. (Note that ``(...) =>`` is special syntax, and does not
+#. Replace the existing constraint tuples in ``GHC.Classes`` with the following
+   definitions and export them from ``Data.Tuple.Experimental`` and ``Prelude.Experimental``. ::


Suggested change

definitions and export them from ``Data.Tuple.Experimental`` and ``Prelude.Experimental``. ::

definitions and export them from ``Data.Tuple.Experimental`` and ``Prelude.Experimental``.

adamgundry · 2023-09-13T07:26:08Z

proposals/0475-tuple-syntax.rst

+#. ``ghc-experimental``:
+   - ``Data.Tuple.Experimental`` will export all tuple-related entities.
+   - ``Data.Sum.Experimental`` will export all sum-related entities.
+   - ``Prelude.Experimental`` will export all of the above.


The RST list syntax is somehow not quite right here.

adamgundry · 2023-09-13T07:57:17Z

proposals/0475-tuple-syntax.rst

-   the definitions below in ``GHC.Tuple`` on ``GHC.TypeLits``.) ::
+#. Export the following definitions from ``Data.Tuple.Experimental`` and
+   ``Prelude.Experimental``. (Implementation note: These would probably end up
+   in a new module ``Data.Tuple.Prim``, due to the dependency from


I think ghc-prim has no stability guarantees, so you should feel free to remove GHC.Tuple.Prim unless there is some implementation reason to keep it.

simonpj

Generally fine, thank you. Just cosmetic suggestions.

simonpj · 2023-09-13T08:06:32Z

proposals/0475-tuple-syntax.rst

+   This proposal lists several definitions to be exported from ``Prelude.Experimental``,
+   but leaves other definitions to be added in separate proposal(s).
+
+   All of the wired-in types must be declared in ``ghc-prim``, and re-exported from


This isn't part of the specification -- it's an implementation note. Mabye

Implementation note: many type definitions will be "wired-in", defined in `ghc-prim`, and simply re-exported from `ghc-experimental`.

simonpj · 2023-09-13T08:07:21Z

proposals/0475-tuple-syntax.rst

-   These would probably end up in a new module ``GHC.Tuple.Prim``, due to the dependency from
-   the definitions below in ``GHC.Tuple`` on ``GHC.TypeLits``.) ::
+#. Replace the existing tuples in ``GHC.Tuple`` with the following definitions
+   and export them from ``Data.Tuple.Experimental`` and ``Prelude.Experimental``. ::


I would not talk about replacing anything. That's an implementation matter. Perhaps just

Export the following type definitions from `Data.Tuple.Experimental`.

simonpj · 2023-09-13T08:10:07Z

proposals/0475-tuple-syntax.rst

+   ``Prelude.Experimental`` exports definitions peculiar to GHC that are safe to
+   use in ordinary code, but whose API may evolve rapidly over subsequent releases.
+   This module is *not* intended as a replacement to ``Prelude``, but instead a
+   complement to it. This module is a counterpart to ``GHC.Exts``, which exports
   many *unsafe* internals.


Perhpas add

`Prelude.Experimental` simple re-exports the all the exports of `Data.Tuple.Experimental` and `Data.Sum.Experimental`, thus module Prelude.Experimental ( module Data.Tuple.Experimental, module Data.Sum.Experimental ) where import Data.Tuple.Experimental import Data.Sum.Experimental Now you don't need to talk about `Prelude.Experimental` any futher. In fact you could specify `Prelude.Experimental` as a separate bullet.

simonpj · 2023-09-13T08:11:03Z

proposals/0475-tuple-syntax.rst

-#. Export the following definitions from ``GHC.Exts`` and ``GHC.Prelude``. These replace
-   the existing tuple definitions (in ``GHC.Classes``) today. (Note that ``(...) =>`` is special syntax, and does not
+#. Replace the existing constraint tuples in ``GHC.Classes`` with the following
+   definitions and export them from ``Data.Tuple.Experimental`` and ``Prelude.Experimental``. ::


Same comment. Don't talk about replacing or about GHC.Classes. Those are implementation matters. Simply write down the definitions visible through Data.Tuple.Experimental.

simonpj · 2023-09-13T08:12:38Z

@simonpj are you happy with the revised state? AFAICS there is no need for further CLC consultation as the only change to base is the export of List from GHC.List, which has already been implemented.

I agree we don't need to consult but I think it would be polite to send an email to the CLC mailing list, drawing their attention to these changes.

tek · 2023-09-13T19:20:44Z

@adamgundry @simonpj I believe I have implemented all your suggestions, and sent an email to the CLC.

proposals/0475-tuple-syntax.rst

Co-authored-by: Adam Gundry <[email protected]>

nomeata · 2023-09-13T20:26:41Z

@adamgundry , shall I merge?

tomjaguarpaw · 2023-09-13T20:33:30Z

There's something I don't understand here. Apparently there is one change to base: "GHC.List will export GHC.Types.List". But GHC.List already exports GHC.Types.List so I don't understand why that's part of the proposal. Perhaps it's supposed to be explained by the following text

The proposal and the implementation of the List part predate the stability practice of introducing experimental entities in ghc-experimental.

but I don't understand what "the List part" means or why that should explain this particular aspect of the proposal.

tomjaguarpaw · 2023-09-13T20:34:37Z

(Please don't hold up moving forward with this proposal on my account. It's probably just me being dim or having forgotten something I knew about before. But the CLC was explicitly informed of this proposal and this CLC member doesn't understand the one small part that seems to impinge on the CLC.)

tek · 2023-09-13T20:45:51Z

@tomjaguarpaw that's just to say that the implementation of the part of the proposal that introduces List and exports it from base was already merged to master and released before we started the split-base discussion and decided to refrain from exporting these new entities from base.

tomjaguarpaw · 2023-09-13T20:53:44Z

So #475 was partially implemented and now you're revising it so that the rest of the implementation uses ghc-experimental instead?

tek · 2023-09-13T20:55:23Z

@tomjaguarpaw that's correct

tomjaguarpaw · 2023-09-13T20:58:43Z

Great, thanks for clarifying!

tek · 2023-09-14T16:00:50Z

small tweak: mentioned Solo deprecation explicitly in the library changes section.

adamgundry · 2023-09-18T07:20:30Z

@adamgundry , shall I merge?

LGTM, yes please!

Ericson2314 approved these changes Jul 11, 2023

View reviewed changes

int-index reviewed Jul 11, 2023

View reviewed changes

simonpj mentioned this pull request Jul 13, 2023

GHC's base libraries: Combining stability with innovation haskellfoundation/tech-proposals#51

Merged

tek added 2 commits August 28, 2023 15:42

Amend 475 to use ghc-experimental for exports

64eb833

use new module names

33179be

tek force-pushed the 475-amendment branch 5 times, most recently from 29ee893 to 3579d91 Compare August 28, 2023 18:02

fix some wrong module names

e7f5dec

tek force-pushed the 475-amendment branch from 3579d91 to e7f5dec Compare August 28, 2023 18:09

adamgundry reviewed Aug 29, 2023

View reviewed changes

tek and others added 3 commits August 29, 2023 20:03

Update proposals/0475-tuple-syntax.rst

e22c1a3

Co-authored-by: Adam Gundry <[email protected]>

fix module names

030c616

link amendment PR

f791ac3

add library changes section, use GHC.Tuple instead of .Prim

8f8f465

adamgundry reviewed Sep 13, 2023

View reviewed changes

simonpj reviewed Sep 13, 2023

View reviewed changes

finishing touches

020c674

tek force-pushed the 475-amendment branch from 518c862 to 020c674 Compare September 13, 2023 19:08

adamgundry reviewed Sep 13, 2023

View reviewed changes

proposals/0475-tuple-syntax.rst Outdated Show resolved Hide resolved

Update proposals/0475-tuple-syntax.rst

d68d528

Co-authored-by: Adam Gundry <[email protected]>

adamgundry approved these changes Sep 13, 2023

View reviewed changes

be more explicit about Solo

d7e609d

tek force-pushed the 475-amendment branch from 7cf5de5 to d7e609d Compare September 14, 2023 17:00

nomeata merged commit 0c76676 into ghc-proposals:master Sep 18, 2023

tek deleted the 475-amendment branch September 18, 2023 16:02

adamgundry added Accepted The committee has decided to accept the proposal Amendment The PR makes changes to a previously-accepted proposal labels Aug 19, 2024

	in a new module ``Data.Tuple.Prim``, due to the dependency from
	in a new module ``GHC.Tuple.Prim``, due to the dependency from

	definitions and export them from ``Data.Tuple.Experimental`` and ``Prelude.Experimental``. ::
	definitions and export them from ``Data.Tuple.Experimental`` and ``Prelude.Experimental``.

Amend 475 to use ghc-experimental for exports #603

Amend 475 to use ghc-experimental for exports #603

Conversation

tek commented Jul 11, 2023 • edited Loading

simonpj commented Jul 11, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tek Jul 12, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

int-index Jul 11, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

int-index Jul 11, 2023 • edited Loading

Choose a reason for hiding this comment

JakobBruenker Jul 11, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simonpj commented Jul 13, 2023

numlit2 commented Jul 13, 2023

adamgundry commented Aug 3, 2023

tek commented Aug 3, 2023

adamgundry commented Aug 4, 2023

tek commented Aug 25, 2023

tek commented Aug 29, 2023

nomeata commented Aug 29, 2023

adamgundry left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simonpj commented Aug 29, 2023

adamgundry commented Aug 30, 2023 • edited Loading

simonpj commented Aug 31, 2023

tek commented Aug 31, 2023

adamgundry left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simonpj left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simonpj commented Sep 13, 2023

tek commented Sep 13, 2023

nomeata commented Sep 13, 2023

tomjaguarpaw commented Sep 13, 2023

tomjaguarpaw commented Sep 13, 2023

tek commented Sep 13, 2023 • edited Loading

tomjaguarpaw commented Sep 13, 2023

tek commented Sep 13, 2023

tomjaguarpaw commented Sep 13, 2023

tek commented Sep 14, 2023

adamgundry commented Sep 18, 2023

tek commented Jul 11, 2023 •

edited

Loading

tek Jul 12, 2023 •

edited

Loading

int-index Jul 11, 2023 •

edited

Loading

int-index Jul 11, 2023 •

edited

Loading

JakobBruenker Jul 11, 2023 •

edited

Loading

adamgundry commented Aug 30, 2023 •

edited

Loading

tek commented Sep 13, 2023 •

edited

Loading