summaryrefslogtreecommitdiff
path: root/docs/users_guide/exts
diff options
context:
space:
mode:
authorKrzysztof Gogolewski <krzysztof.gogolewski@tweag.io>2021-08-29 23:07:43 +0200
committerMarge Bot <ben+marge-bot@smart-cactus.org>2021-09-08 03:00:57 -0400
commitdcc1599f74d8115b3bd1bd87648866d89070a7e9 (patch)
tree9c4802eb4d683f39fb414b22b8ac8ee5cfa075ba /docs/users_guide/exts
parentfb1e0a5da67f075ae4f487e111fcf69d1dfcd42f (diff)
downloadhaskell-dcc1599f74d8115b3bd1bd87648866d89070a7e9.tar.gz
Minor doc fixes
- Fix markup in 9.4 release notes - Document -ddump-cs-trace - Mention that ImpredicativeTypes is really supported only since 9.2 - Remove "There are some restrictions on the use of unboxed tuples". This used to be a list, but all those restrictions were removed. - Mark -fimplicit-import-qualified as documented - Remove "The :main and :run command" - duplicated verbatim in options - Avoid calling "main" a function (cf. #7816) - Update System.getArgs: the old location was before hierarchical modules - Note that multiplicity multiplication is not supported (#20319)
Diffstat (limited to 'docs/users_guide/exts')
-rw-r--r--docs/users_guide/exts/impredicative_types.rst9
-rw-r--r--docs/users_guide/exts/linear_types.rst1
-rw-r--r--docs/users_guide/exts/primitives.rst38
3 files changed, 25 insertions, 23 deletions
diff --git a/docs/users_guide/exts/impredicative_types.rst b/docs/users_guide/exts/impredicative_types.rst
index 01d6476923..63017b8a2e 100644
--- a/docs/users_guide/exts/impredicative_types.rst
+++ b/docs/users_guide/exts/impredicative_types.rst
@@ -8,7 +8,7 @@ Impredicative polymorphism
Implies :extension:`RankNTypes`.
:implies: :extension:`RankNTypes`
- :since: 6.10.1
+ :since: 9.2.1 (unreliable in 6.10 - 9.0)
Allow impredicative polymorphic types.
@@ -34,13 +34,13 @@ inference algorithm. It is described in the paper
Switching on :extension:`ImpredicativeTypes`
-- Switches on :extension: `RankNTypes`
+- Switches on :extension:`RankNTypes`
- Allows user-written types to have foralls under type constructors, not just under arrows.
For example ``f :: Maybe (forall a. [a] -> [a])`` is a legal type signature.
- Allows polymorphic types in Visible Type Application
- (when :extension: `TypeApplications` is enabled). For example, you
+ (when :extension:`TypeApplications` is enabled). For example, you
can write ``reverse @(forall b. b->b) xs``. Using VTA with a
polymorphic type argument is useful in cases when Quick Look cannot
infer the correct instantiation.
@@ -54,3 +54,6 @@ For many years GHC has a special case for the function ``($)``, that allows it
to typecheck an application like ``runST $ (do { ... })``, even though that
instantiation may be impredicative. This special case remains: even without
:extension:`ImpredicativeTypes` GHC switches on Quick Look for applications of ``($)``.
+
+This flag was available in earlier versions of GHC (6.10.1 - 9.0),
+but the behavior was unpredictable and not officially supported.
diff --git a/docs/users_guide/exts/linear_types.rst b/docs/users_guide/exts/linear_types.rst
index 5ed710d1c5..9985310d49 100644
--- a/docs/users_guide/exts/linear_types.rst
+++ b/docs/users_guide/exts/linear_types.rst
@@ -152,6 +152,7 @@ missing pieces.
- Multiplicity polymorphism is incomplete and experimental. You may
have success using it, or you may not. Expect it to be really unreliable.
+ (Multiplicity multiplication is not supported yet.)
- There is currently no support for multiplicity annotations such as
``x :: a %p``, ``\(x :: a %p) -> ...``.
- A ``case`` expression may consume its scrutinee ``One`` time,
diff --git a/docs/users_guide/exts/primitives.rst b/docs/users_guide/exts/primitives.rst
index 4f61f75f93..578ca1c4f7 100644
--- a/docs/users_guide/exts/primitives.rst
+++ b/docs/users_guide/exts/primitives.rst
@@ -172,35 +172,33 @@ primitive operations listed in ``primops.txt.pp`` return unboxed tuples.
In particular, the ``IO`` and ``ST`` monads use unboxed tuples to avoid
unnecessary allocation during sequences of operations.
-There are some restrictions on the use of unboxed tuples:
+The typical use of unboxed tuples is simply to return multiple
+values, binding those multiple results with a ``case`` expression,
+thus:
-- The typical use of unboxed tuples is simply to return multiple
- values, binding those multiple results with a ``case`` expression,
- thus:
+::
- ::
-
- f x y = (# x+1, y-1 #)
- g x = case f x x of { (# a, b #) -> a + b }
+ f x y = (# x+1, y-1 #)
+ g x = case f x x of { (# a, b #) -> a + b }
- You can have an unboxed tuple in a pattern binding, thus
+You can have an unboxed tuple in a pattern binding, thus
- ::
+::
- f x = let (# p,q #) = h x in ..body..
+ f x = let (# p,q #) = h x in ..body..
- If the types of ``p`` and ``q`` are not unboxed, the resulting
- binding is lazy like any other Haskell pattern binding. The above
- example desugars like this:
+If the types of ``p`` and ``q`` are not unboxed, the resulting
+binding is lazy like any other Haskell pattern binding. The above
+example desugars like this:
- ::
+::
- f x = let t = case h x of { (# p,q #) -> (p,q) }
- p = fst t
- q = snd t
- in ..body..
+ f x = let t = case h x of { (# p,q #) -> (p,q) }
+ p = fst t
+ q = snd t
+ in ..body..
- Indeed, the bindings can even be recursive.
+Indeed, the bindings can even be recursive.
.. _unboxed-sums: