Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
GHC
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Requirements
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Package Registry
Model registry
Operate
Terraform modules
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
psilospore - Syed Jafri
GHC
Commits
7a0cab9b
Commit
7a0cab9b
authored
17 years ago
by
Simon Peyton Jones
Browse files
Options
Downloads
Patches
Plain Diff
Improve manual entry for binding lexically scoped type variables in pattern signatures
parent
0093a282
Branches
master
Branches containing commit
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
docs/users_guide/glasgow_exts.xml
+29
-6
29 additions, 6 deletions
docs/users_guide/glasgow_exts.xml
with
29 additions
and
6 deletions
docs/users_guide/glasgow_exts.xml
+
29
−
6
View file @
7a0cab9b
...
...
@@ -4450,7 +4450,7 @@ type variable <literal>s</literal> into scope, in the annotated expression
<title>
Pattern type signatures
</title>
<para>
A type signature may occur in any pattern; this is a
<emphasis>
pattern type
signature
</emphasis>
.
signature
</emphasis>
.
For example:
<programlisting>
-- f and g assume that 'a' is already in scope
...
...
@@ -4463,9 +4463,27 @@ already in scope (i.e. bound by the enclosing context), matters are simple: the
signature simply constrains the type of the pattern in the obvious way.
</para>
<para>
There is only one situation in which you can write a pattern type signature that
mentions a type variable that is not already in scope, namely in pattern match
of an existential data constructor. For example:
Unlike expression and declaration type signatures, pattern type signatures are not implictly generalised.
The pattern in a
<emphasis>
patterm binding
</emphasis>
may only mention type variables
that are already in scope. For example:
<programlisting>
f :: forall a. [a] -> (Int, [a])
f xs = (n, zs)
where
(ys::[a], n) = (reverse xs, length xs) -- OK
zs::[a] = xs ++ ys -- OK
Just (v::b) = ... -- Not OK; b is not in scope
</programlisting>
Here, the pattern signatures for
<literal>
ys
</literal>
and
<literal>
zs
</literal>
are fine, but the one for
<literal>
v
</literal>
is not because
<literal>
b
</literal>
is
not in scope.
</para>
<para>
However, in all patterns
<emphasis>
other
</emphasis>
than pattern bindings, a pattern
type signature may mention a type variable that is not in scope; in this case,
<emphasis>
the signature brings that type variable into scope
</emphasis>
.
This is particularly important for existential data constructors. For example:
<programlisting>
data T = forall a. MkT [a]
...
...
@@ -4475,14 +4493,19 @@ of an existential data constructor. For example:
t3::[a] = [t,t,t]
</programlisting>
Here, the pattern type signature
<literal>
(t::a)
</literal>
mentions a lexical type
variable that is not already in scope. Indeed, it
cannot
already be in scope,
variable that is not already in scope. Indeed, it
<emphasis>
cannot
</emphasis>
already be in scope,
because it is bound by the pattern match. GHC's rule is that in this situation
(and only then), a pattern type signature can mention a type variable that is
not already in scope; the effect is to bring it into scope, standing for the
existentially-bound type variable.
</para>
<para>
If this seems a little odd, we think so too. But we must have
When a pattern type signature binds a type variable in this way, GHC insists that the
type variable is bound to a
<emphasis>
rigid
</emphasis>
, or fully-known, type variable.
This means that any user-written type signature always stands for a completely known type.
</para>
<para>
If all this seems a little odd, we think so too. But we must have
<emphasis>
some
</emphasis>
way to bring such type variables into scope, else we
could not name existentially-bound type variables in subsequent type signatures.
</para>
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment