From 4cab68974dba3e674016514c939946ce60e58273 Mon Sep 17 00:00:00 2001 From: Adam Sandberg Ericsson Date: Mon, 15 Jun 2020 18:07:49 +0100 Subject: docs: fix formatting in users guide --- docs/users_guide/8.12.1-notes.rst | 13 ++++++------- docs/users_guide/extending_ghc.rst | 2 +- docs/users_guide/exts/explicit_forall.rst | 6 +++--- docs/users_guide/exts/gadt_syntax.rst | 14 +++++++------- docs/users_guide/using-warnings.rst | 3 +-- 5 files changed, 18 insertions(+), 20 deletions(-) (limited to 'docs') diff --git a/docs/users_guide/8.12.1-notes.rst b/docs/users_guide/8.12.1-notes.rst index 47f2fbfb87..a66ab06514 100644 --- a/docs/users_guide/8.12.1-notes.rst +++ b/docs/users_guide/8.12.1-notes.rst @@ -21,11 +21,10 @@ Highlights * Pattern-Match Coverage Checking - - The revamp of the pattern-match coverage checker that started in 8.10 concludes with this release and implements the + - The revamp of the pattern-match coverage checker that started in 8.10 concludes with this release and implements the novel `*Lower Your Guards* `_ algorithm. - - Compared to 8.10, end users might notice improvements to "long-distance information": :: haskell + - Compared to 8.10, end users might notice improvements to "long-distance information": :: - :linenos: f True = 1 f x = ... case x of { False -> 2; True -> 3 } ... @@ -125,14 +124,14 @@ Language MkT2 :: (forall a. a -> T) ``MkT1`` and ``MkT2`` are rejected because the lack of an outermost - ``forall`` triggers implicit quantification, making the explicit ``forall``s + ``forall`` triggers implicit quantification, making the explicit ``forall``\ s nested. Furthermore, GADT constructors do not permit the use of nested - ``forall``s, as explained in :ref:`formal-gadt-syntax`. + ``forall``\ s, as explained in :ref:`formal-gadt-syntax`. - In addition to rejecting nested ``forall``s, GHC is now more stringent about + In addition to rejecting nested ``forall``\ s, GHC is now more stringent about rejecting uses of nested *contexts* in GADT constructors. For example, the following example, which previous versions of GHC would accept, is now - rejected: + rejected: :: data U a where MkU :: (Show a => U a) diff --git a/docs/users_guide/extending_ghc.rst b/docs/users_guide/extending_ghc.rst index cc16b8f2df..b44038e02c 100644 --- a/docs/users_guide/extending_ghc.rst +++ b/docs/users_guide/extending_ghc.rst @@ -775,7 +775,7 @@ each case: package/field-n To read an interface file from an external tool without linking to GHC, the format -is described at `Extensible Interface Files`_. +is described at `Extensible Interface Files `_. Source plugin example ^^^^^^^^^^^^^^^^^^^^^ diff --git a/docs/users_guide/exts/explicit_forall.rst b/docs/users_guide/exts/explicit_forall.rst index 6b4fc9cef7..8287e510dc 100644 --- a/docs/users_guide/exts/explicit_forall.rst +++ b/docs/users_guide/exts/explicit_forall.rst @@ -112,9 +112,9 @@ Notes: {-# RULES "f" forall (g :: forall a. a -> b) x. f g x = g x :: b #-} -- GADT constructors are extra particular about their ``forall``s. In addition +- GADT constructors are extra particular about their ``forall``\ s. In addition to adhering to the ``forall``-or-nothing rule, GADT constructors also forbid - nested ``forall``s. For example, GHC would reject the following GADT: :: + nested ``forall``\ s. For example, GHC would reject the following GADT: :: data T where MkT :: (forall a. a -> b -> T) @@ -122,4 +122,4 @@ Notes: Because of the lack of an outermost ``forall`` in the type of ``MkT``, the ``b`` would be implicitly quantified. In effect, it would be as if one had written ``MkT :: forall b. (forall a. a -> b -> T)``, which contains nested - ``forall``s. See :ref:`formal-gadt-syntax`. + ``forall``\ s. See :ref:`formal-gadt-syntax`. diff --git a/docs/users_guide/exts/gadt_syntax.rst b/docs/users_guide/exts/gadt_syntax.rst index 9b20c27ab1..970d2fce90 100644 --- a/docs/users_guide/exts/gadt_syntax.rst +++ b/docs/users_guide/exts/gadt_syntax.rst @@ -161,23 +161,23 @@ Where: - ``btype`` is a type that is not allowed to have an outermost ``forall``/``=>`` unless it is surrounded by parentheses. For example, - ``forall a. a`` and ``Eq a => a`` are not legal ``btype``s, but + ``forall a. a`` and ``Eq a => a`` are not legal ``btype``\ s, but ``(forall a. a)`` and ``(Eq a => a)`` are legal. - ``ctype`` is a ``btype`` that has no restrictions on an outermost - ``forall``/``=>``, so ``forall a. a`` and ``Eq a => a`` are legal ``ctype``s. -- ``return_type`` is a type that is not allowed to have ``forall``s, ``=>``s, - or ``->``s. + ``forall``/``=>``, so ``forall a. a`` and ``Eq a => a`` are legal ``ctype``\ s. +- ``return_type`` is a type that is not allowed to have ``forall``\ s, ``=>``\ s, + or ``->``\ s. This is a simplified grammar that does not fully delve into all of the implementation details of GHC's parser (such as the placement of Haddock comments), but it is sufficient to attain an understanding of what is syntactically allowed. Some further various observations about this grammar: -- GADT constructor types are currently not permitted to have nested ``forall``s - or ``=>``s. (e.g., something like ``MkT :: Int -> forall a. a -> T`` would be +- GADT constructor types are currently not permitted to have nested ``forall``\ s + or ``=>``\ s. (e.g., something like ``MkT :: Int -> forall a. a -> T`` would be rejected.) As a result, ``gadt_sig`` puts all of its quantification and constraints up front with ``opt_forall`` and ``opt_context``. Note that - higher-rank ``forall``s and ``=>``s are only permitted if they do not appear + higher-rank ``forall``\ s and ``=>``\ s are only permitted if they do not appear directly to the right of a function arrow in a `prefix_gadt_body`. (e.g., something like ``MkS :: Int -> (forall a. a) -> S`` is allowed, since parentheses separate the ``forall`` from the ``->``.) diff --git a/docs/users_guide/using-warnings.rst b/docs/users_guide/using-warnings.rst index ca1945c743..990d478af6 100644 --- a/docs/users_guide/using-warnings.rst +++ b/docs/users_guide/using-warnings.rst @@ -239,8 +239,7 @@ of ``-W(no-)*``. - ``Data.List`` due to the future addition of ``Data.List.singleton`` and specialisation of exports to the ``[]`` type. See the - :ref:`mailing list - ` + `mailing list `_ for details. This warning can be addressed by either adding an explicit import list or -- cgit v1.2.1