From 76a4d11b5f2077bbe057deac812f5b211e6a5d1d Mon Sep 17 00:00:00 2001
From: Jaro Reinders <jaro.reinders@gmail.com>
Date: Mon, 14 Aug 2023 17:50:46 +0200
Subject: [PATCH] Remove Ptr example from roles docs
---
docs/users_guide/exts/roles.rst | 21 +--------------------
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/docs/users_guide/exts/roles.rst b/docs/users_guide/exts/roles.rst
index 7e5384e53c0e..43c0d1f0d132 100644
--- a/docs/users_guide/exts/roles.rst
+++ b/docs/users_guide/exts/roles.rst
@@ -155,26 +155,7 @@ Role annotations
Allow role annotation syntax.
Sometimes the programmer wants to constrain the inference process. For
-example, the base library contains the following definition: ::
-
- data Ptr a = Ptr Addr#
-
-The idea is that ``a`` should really be a representational parameter,
-but role inference assigns it to phantom. This makes some level of
-sense: a pointer to an ``Int`` really is representationally the same as
-a pointer to a ``Bool``. But, that's not at all how we want to use
-``Ptr``\ s! So, we want to be able to say ::
-
- type role Ptr representational
- data Ptr a = Ptr Addr#
-
-The ``type role`` (enabled with :extension:`RoleAnnotations`) declaration
-forces the parameter ``a`` to be at role representational, not role
-phantom. GHC then checks the user-supplied roles to make sure they don't
-break any promises. It would be bad, for example, if the user could make
-``BadIdea``\'s role be representational.
-
-As another example, we can consider a type ``Set a`` that represents a
+example, we can consider a type ``Set a`` that represents a
set of data, ordered according to ``a``\'s ``Ord`` instance. While it
would generally be type-safe to consider ``a`` to be at role
representational, it is possible that a ``newtype`` and its base type
--
GitLab