Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Amend 475 to use ghc-experimental for exports #603

Merged
merged 10 commits into from
Sep 18, 2023
Merged

Amend 475 to use ghc-experimental for exports #603

Changes from 3 commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
64eb833
Amend 475 to use ghc-experimental for exports
tek Jul 11, 2023
33179be
use new module names
tek Aug 25, 2023
e7f5dec
fix some wrong module names
tek Aug 28, 2023
e22c1a3
Update proposals/0475-tuple-syntax.rst
tek Aug 29, 2023
030c616
fix module names
tek Aug 29, 2023
f791ac3
link amendment PR
tek Aug 29, 2023
8f8f465
add library changes section, use GHC.Tuple instead of .Prim
tek Aug 31, 2023
020c674
finishing touches
tek Sep 13, 2023
d68d528
Update proposals/0475-tuple-syntax.rst
tek Sep 13, 2023
d7e609d
be more explicit about Solo
tek Sep 14, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
90 changes: 45 additions & 45 deletions proposals/0475-tuple-syntax.rst
View file
Open in desktop
adamgundry marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
Expand Up @@ -63,18 +63,25 @@ variable in a bit of code. This allows us to e.g. refer to ``Tuple2`` and ``Tupl
Proposed Change Specification
-----------------------------

1. Create a new module in ``base`` called ``GHC.Prelude``. This module exports definitions
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 ``Prelude.Experimental``,
``Data.Tuple.Experimental`` and ``Data.Sum.Experimental``.
Since this new paradigm may evolve in response to users' experience, we want
to avoid committing to an API in ``base`` too early, and therefore choose the
new package as the home for the exports of the new entities.

``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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


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

#. Export the following definitions from ``GHC.Tuple`` and ``GHC.Prelude``. (Implementation note:
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``.) ::
#. 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

works!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adamgundry what do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

the definitions below in ``Data.Tuple.Experimental`` on ``GHC.TypeLits``.) ::

data Unit = ()
data Solo a = MkSolo a -- this is a change from today's `data Solo a = Solo a`
Expand All @@ -94,7 +101,7 @@ Proposed Change Specification
-- ...
data Tuple64 ... = (...)

#. Export the following definitions from ``GHC.Exts`` and ``GHC.Prelude``. These replace
#. Export the following definitions from ``Data.Tuple.Experimental`` and ``Prelude.Experimental``. These replace
the existing tuple definitions (in ``GHC.Classes``) today. (Note that ``(...) =>`` is special syntax, and does not
construct tuples. See more on this point `below <#constraint-special-syntax>`_.)::

Expand All @@ -115,7 +122,7 @@ Proposed Change Specification
class (...) => CTuple64 ...
instance (...) => CTuple64 ...

#. Export the following pseudo-definitions from ``GHC.Exts``. (Implementation note:
#. Export the following pseudo-definitions from ``Data.Tuple.Experimental``. (Implementation note:
These would likely be exported from ``GHC.Prim`` originally.) ::

type Unit# :: TYPE (TupleRep [])
Expand All @@ -135,6 +142,9 @@ Proposed Change Specification
type Tuple64# :: TYPE r1 -> ... -> TYPE r64 -> TYPE (TupleRep [r1, ..., r64])
data Tuple64# ... = (# ... #)

#. Export the following pseudo-definitions from ``Data.Sum.Experimental``. (Implementation note:
These would likely be exported from ``GHC.Prim`` originally.) ::

-- NB: There are no 0-sums or 1-sums in Haskell, today or tomorrow.

type Sum2# :: TYPE r1 -> TYPE r2 -> TYPE (SumRep [r1, r2])
Expand All @@ -150,7 +160,7 @@ Proposed Change Specification

#. Remove existing tuple definitions from ``GHC.Tuple``.

#. Export the following definitions from ``GHC.Tuple``::
#. Export the following definitions from ``Data.Tuple.Experimental``::

type Length :: List a -> Nat -- not exported
type family Length xs where
Expand Down Expand Up @@ -210,6 +220,8 @@ Proposed Change Specification
Tuple# (a, b, ..., bk, bl) = Tuple64# a b ... bk bl
Tuple# @reps _ = TypeError (ShowType (Length reps) :<>: Text " is too large; the maximum size of a tuple is 64.")

#. Export the following definitions from ``Data.Sum.Experimental``::

type Sum# :: forall (reps :: List RuntimeRep). TupleArgKind# reps -> TYPE (SumRep reps)
type family Sum# ts where
Sum# () = TypeError (Text "GHC does not support empty unboxed sums. Consider Data.Void.Void instead.")
Expand All @@ -224,7 +236,7 @@ Proposed Change Specification

data List a = [] | a : List a

#. Re-export ``List`` from ``GHC.List`` and ``GHC.Prelude``.
#. Re-export ``List`` from ``GHC.List`` and ``Prelude.Experimental``.

#. Introduce a new extension ``-XListTuplePuns``; this extension is part
of ``-XHaskell98``, ``-XHaskell2010``, and ``-XGHC2021``. It is thus on by default.
Expand All @@ -237,16 +249,16 @@ Proposed Change Specification
#. An occurrence of ``[ty]`` in type-syntax is a synonym for ``GHC.List.List ty``.

#. An occurrence of ``()`` in type-syntax, where the type is not expected to be of kind ``Constraint``,
is a synonym for ``GHC.Tuple.Unit``.
is a synonym for ``GHC.Tuple.Prim.Unit``.

#. An occurrence of ``(,,...,,)`` where there are *n* commas (for *n* ≧ 1) in type-syntax
is a synonym for ``GHC.Tuple.Tuple<n+1>``.
is a synonym for ``GHC.Tuple.Prim.Tuple<n+1>``.

#. An occurrence of ``(ty1,ty2,...,ty<n-1>,ty<n>)`` (for *n* ≧ 2) in type-syntax, where neither the type
is expected to be of kind ``Constraint`` and either none of the ``ty<i>`` are inferred to have kind ``Constraint``
or there exists a ``ty<i>`` inferred to kind ``Type`` and none of the ``ty<j>`` (with *j* < i) are inferred to have
kind ``Constraint``, is
a synonym for ``GHC.Tuple.Tuple<n>`` ``ty1 ty2 ... ty<n-1> ty<n>``. (This rule retains today's behavior.)
a synonym for ``GHC.Tuple.Prim.Tuple<n>`` ``ty1 ty2 ... ty<n-1> ty<n>``. (This rule retains today's behavior.)

#. With ``-XUnboxedTuples``, an occurrence of ``(# #)`` in type-syntax is a synonym for ``GHC.Exts.Unit#``.

Expand All @@ -265,41 +277,41 @@ Proposed Change Specification
synonym for ``GHC.Exts.Sum<n># ty1 ty2 ... ty<n-1> ty<n>``.

#. An occurrence of ``()`` in type-syntax, where the type is expected to be of kind ``Constraint``,
is a synonym for ``GHC.Tuple.CUnit``.
is a synonym for ``GHC.Classes.CUnit``.

#. An occurrence of ``(ty1, ty2, ..., ty<n-1>, ty<n>)`` (for *n* ≧ 2) in type-syntax, where the type is
expected to be of kind ``Constraint``, is a synonym for ``GHC.Tuple.CTuple<n> ty1 ty2 ... ty<n-1> ty<n>``.
expected to be of kind ``Constraint``, is a synonym for ``Data.Tuple.Experimental.CTuple<n> ty1 ty2 ... ty<n-1> ty<n>``.

#. An occurrence of ``(ty1, ty2, ..., ty<n-1>, ty<n>)`` (for *n* ≧ 2) in type-syntax, where the first
``ty<i>`` inferred to have kind ``Type`` or ``Constraint`` has kind ``Constraint``, is a synonym
for ``GHC.Tuple.CTuple<n> ty1 ty2 ... ty<n-1> ty<n>``.
for ``GHC.Classes.CTuple<n> ty1 ty2 ... ty<n-1> ty<n>``.

#. An unapplied occurrence of ``GHC.List.List`` is pretty-printed as ``[]``.

#. An occurrence of ``GHC.List.List ty`` is pretty-printed as ``[ty]``.

#. An occurrence of ``GHC.Tuple.Unit`` is pretty-printed as ``()``.
#. An occurrence of ``GHC.Tuple.Prim.Unit`` is pretty-printed as ``()``.

#. An occurrence of ``GHC.Tuple.Tuple<n> ty1 ty2 ... ty<n>`` is pretty-printed as ``(ty1, ty2, ..., ty<n>)``.
#. An occurrence of ``GHC.Tuple.Prim.Tuple<n> ty1 ty2 ... ty<n>`` is pretty-printed as ``(ty1, ty2, ..., ty<n>)``.

#. An occurrence of ``GHC.Tuple.Tuple<n>``, but not applied to a full *n* arguments, is pretty-printed as ``(,,...,,)``,
#. An occurrence of ``GHC.Tuple.Prim.Tuple<n>``, but not applied to a full *n* arguments, is pretty-printed as ``(,,...,,)``,
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 ``(# #)``.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


#. An occurrence of ``GHC.Exts.Tuple<n># ty1 ty2 ... ty<n>`` is pretty-printed as ``(# ty1, ty2, ..., ty<n> #)``.
#. An occurrence of ``GHC.Types.Tuple<n># ty1 ty2 ... ty<n>`` is pretty-printed as ``(# ty1, ty2, ..., ty<n> #)``.

#. An occurrence of ``GHC.Exts.Tuple<n>#``, but not applied to a full *n* arguments, is pretty-printed as ``(#,,...,,#)``,
#. An occurrence of ``GHC.Types.Tuple<n>#``, but not applied to a full *n* arguments, is pretty-printed as ``(#,,...,,#)``,
where there are *n-1* commas.

#. An occurrence of ``GHC.Exts.Sum<n># ty1 ty2 ... ty<n>`` is pretty-printed as ``(# ty1 | ty2 | ... | ty<n> #)``.
#. An occurrence of ``GHC.Types.Sum<n># ty1 ty2 ... ty<n>`` is pretty-printed as ``(# ty1 | ty2 | ... | ty<n> #)``.

#. An occurrence of ``GHC.Exts.Sum<n>#``, but not applied to a full *n* arguments, is pretty-printed as ``(# | | ... | | #)``,
#. An occurrence of ``GHC.Types.Sum<n>#``, but not applied to a full *n* arguments, is pretty-printed as ``(# | | ... | | #)``,
where there are *n-1* pipes.

#. An occurrence of ``GHC.Tuple.CUnit`` is pretty-printed as ``()``.
#. An occurrence of ``GHC.Classes.CUnit`` is pretty-printed as ``()``.

#. An occurrence of ``GHC.Tuple.CTuple<n> ty1 ty2 ... ty<n>`` is pretty-printed as ``(ty1, ty2, ..., ty<n>)``.
#. An occurrence of ``GHC.Classes.CTuple<n> ty1 ty2 ... ty<n>`` is pretty-printed as ``(ty1, ty2, ..., ty<n>)``.

#. With ``-XNoListTuplePuns``:

Expand All @@ -310,13 +322,13 @@ Proposed Change Specification

#. A use of ``(# ... | ... | ... #)``, where each of the ``...`` is filled in, (among other arities) is now disallowed.

#. An occurrence of ``GHC.Tuple.Tuple<n> ty1 ty2 ... ty<n>`` is pretty-printed as ``Tuple (ty1, ty2, ..., ty<n>)``.
#. An occurrence of ``GHC.Tuple.Prim.Tuple<n> ty1 ty2 ... ty<n>`` is pretty-printed as ``Tuple (ty1, ty2, ..., ty<n>)``.

#. An occurrence of ``GHC.Tuple.CTuple<n> ty1 ty2 ... ty<n>`` is pretty-printed as ``Constraints (ty1, ty2, ..., ty<n>)``.
#. An occurrence of ``GHC.Classes.CTuple<n> ty1 ty2 ... ty<n>`` is pretty-printed as ``Constraints (ty1, ty2, ..., ty<n>)``.

#. An occurrence of ``GHC.Exts.Tuple<n># ty1 ty2 ... ty<n>`` is pretty-printed as ``Tuple# (ty1, ty2, ..., ty<n>)``.
#. An occurrence of ``GHC.Types.Tuple<n># ty1 ty2 ... ty<n>`` is pretty-printed as ``Tuple# (ty1, ty2, ..., ty<n>)``.

#. An occurrence of ``GHC.Exts.Sum<n># ty1 ty2 ... ty<n>`` is pretty-printed as ``Sum# (ty1, ty2, ..., ty<n>)``.
#. An occurrence of ``GHC.Types.Sum<n># ty1 ty2 ... ty<n>`` is pretty-printed as ``Sum# (ty1, ty2, ..., ty<n>)``.

#. A use of ``'[ty1, ..., ty<n>]`` (for *n* ≧ 0) is now disallowed.

Expand Down Expand Up @@ -462,18 +474,6 @@ Alternatives
``-XNoListTuplePuns`` is not necessary to avoid punning, but is done only for
consistency. We could skip this, but I prefer keeping it as proposed.

#. There was an objection in the commentary about the name ``GHC.Prelude``. I continue
to like that name: the module exports basic definitions one will likely want when
using the GHC compiler for Haskell. However, an alternative might be
``GHC.SafeExts`` or something similar. (I'd actually rather have the safe extensions
be in ``GHC.Exts`` and the unsafe ones be in ``GHC.Exts.Unsafe``, but that ship has
sailed and is not worth calling back to port.)

Note that GHC itself already has a module named ``GHC.Prelude`` that would have to
be renamed if we keep ``GHC.Prelude`` as the choice for the new module in ``base``.
This is purely an implementation detail, though, and would not affect users (except
via the GHC API).

#. The following definitions were included in an earlier version of this proposal,
but the committee decided we were better without::

Expand Down