generated by the call to <literal>elem</literal>, so that the type of
<literal>insert</literal> itself has no <literal>Eq</literal> constraint.
</para>
-<para>This behaviour contrasts with Haskell 98's peculiar treament of
+<para>This behaviour contrasts with Haskell 98's peculiar treatment of
contexts on a data type declaration (Section 4.2.1 of the Haskell 98 Report).
-In Haskell 98 the defintion
+In Haskell 98 the definition
<programlisting>
data Eq a => Set' a = MkSet' [a]
</programlisting>
<para>
At the moment, record updates are not yet possible with GADT-style declarations,
so support is limited to record construction, selection and pattern matching.
-For exmaple
+For example
<programlisting>
aPerson = Adult { name = "Fred", children = [] }
<listitem><para>
You cannot use a <literal>deriving</literal> clause for a GADT; only for
-an ordianary data type.
+an ordinary data type.
</para></listitem>
<listitem><para>
<para>
GHC takes a conservative position: it accepts the first two, but not the third. The rule is this:
each constraint in the inferred instance context must consist only of type variables,
-with no repititions.
+with no repetitions.
</para>
<para>
This rule is applied regardless of flags. If you want a more exotic context, you can write
deriving instance MonadState Int Foo
</programlisting>
GHC always treats the <emphasis>last</emphasis> parameter of the instance
-(<literal>Foo</literal> in this exmample) as the type whose instance is being derived.
+(<literal>Foo</literal> in this example) as the type whose instance is being derived.
</para>
</sect2>
The willingness to be overlapped or incoherent is a property of
the <emphasis>instance declaration</emphasis> itself, controlled by the
presence or otherwise of the <option>-XOverlappingInstances</option>
-and <option>-XIncoherentInstances</option> flags when that mdodule is
+and <option>-XIncoherentInstances</option> flags when that module is
being defined. Neither flag is required in a module that imports and uses the
instance declaration. Specifically, during the lookup process:
<itemizedlist>
fromString cs = cs
</programlisting>
The class <literal>IsString</literal> is not in scope by default. If you want to mention
-it explicitly (for exmaple, to give an instance declaration for it), you can import it
+it explicitly (for example, to give an instance declaration for it), you can import it
from module <literal>GHC.Exts</literal>.
</para>
<para>
Boston, Jan 2000.
</para>
-<para>(Most of the following, stil rather incomplete, documentation is
+<para>(Most of the following, still rather incomplete, documentation is
due to Jeff Lewis.)</para>
<para>Implicit parameter support is enabled with the option
right-hand side, so the implicit parameter <literal>?acc</literal> is not
passed to the recursive call. In the latter case, because <literal>len_acc2</literal>
has a type signature, the recursive call is made to the
-<emphasis>polymoprhic</emphasis> version, which takes <literal>?acc</literal>
+<emphasis>polymorphic</emphasis> version, which takes <literal>?acc</literal>
as an implicit parameter. So we get the following results in GHCi:
<programlisting>
Prog> len1 "hello"
<itemizedlist>
<listitem> <para> '<literal>?x</literal>' and '<literal>%x</literal>'
are entirely distinct implicit parameters: you
- can use them together and they won't intefere with each other. </para>
+ can use them together and they won't interfere with each other. </para>
</listitem>
<listitem> <para> You can bind linear implicit parameters in 'with' clauses. </para> </listitem>
design.)</para></listitem>
<listitem><para>Furthermore, distinct lexical type variables stand for distinct
type variables. This means that every programmer-written type signature
-(includin one that contains free scoped type variables) denotes a
+(including one that contains free scoped type variables) denotes a
<emphasis>rigid</emphasis> type; that is, the type is fully known to the type
checker, and no inference is involved.</para></listitem>
<listitem><para>Lexical type variables may be alpha-renamed freely, without
</itemizedlist>
</para>
<para>
-In Haskell, a programmer-written type signature is implicitly quantifed over
+In Haskell, a programmer-written type signature is implicitly quantified over
its free type variables (<ulink
url="http://haskell.org/onlinereport/decls.html#sect4.1.2">Section
4.1.2</ulink>
g (x::a) = x
h ((x,y) :: (Int,Bool)) = (y,x)
</programlisting>
-In the case where all the type variables in the pattern type sigature are
+In the case where all the type variables in the pattern type signature are
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>
If 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 subequent type signatures.
+could not name existentially-bound type variables in subsequent type signatures.
</para>
<para>
This is (now) the <emphasis>only</emphasis> situation in which a pattern type
<literal>g</literal> is typechecked first, separately from that for
<literal>f</literal>,
because the reference to <literal>f</literal> in <literal>g</literal>'s right
-hand side is ingored by the dependency analysis. Then <literal>g</literal>'s
+hand side is ignored by the dependency analysis. Then <literal>g</literal>'s
type is generalised, to get
<programlisting>
g :: Ord a => a -> Bool
</programlisting>
-Now, the defintion for <literal>f</literal> is typechecked, with this type for
+Now, the definition for <literal>f</literal> is typechecked, with this type for
<literal>g</literal> in the type environment.
</para>
<para>Then compile it again with <option>-prof</option>, and
additionally use <option>-osuf
p_o</option><indexterm><primary><option>-osuf</option></primary></indexterm>
- to name the object files differentliy (you can choose any suffix
+ to name the object files differently (you can choose any suffix
that isn't the normal object suffix here). GHC will automatically
load the object files built in the first step when executing splice
expressions. If you omit the <option>-osuf</option> flag when
g7 x = case f x of { !y -> body }
</programlisting>
The functions <literal>g5</literal> and <literal>g6</literal> mean exactly the same thing.
-But <literal>g7</literal> evalutes <literal>(f x)</literal>, binds <literal>y</literal> to the
+But <literal>g7</literal> evaluates <literal>(f x)</literal>, binds <literal>y</literal> to the
result, and then evaluates <literal>body</literal>.
</para><para>
Bang patterns work in <literal>let</literal> and <literal>where</literal>
<para>When you compile any module that imports and uses any
of the specified entities, GHC will print the specified
message.</para>
- <para> You can only depecate entities declared at top level in the module
+ <para> You can only deprecate entities declared at top level in the module
being compiled, and you can only use unqualified names in the list of
entities being deprecated. A capitalised name, such as <literal>T</literal>
refers to <emphasis>either</emphasis> the type constructor <literal>T</literal>
<programlisting>
{-# SPECIALIZE f :: <type> #-}
</programlisting>
- is valid if and only if the defintion
+ is valid if and only if the definition
<programlisting>
f_spec :: <type>
f_spec = f
<para>A <literal>SPECIALIZE</literal> pragma can optionally be followed with a
<literal>INLINE</literal> or <literal>NOINLINE</literal> pragma, optionally
followed by a phase, as described in <xref linkend="inline-noinline-pragma"/>.
-The <literal>INLINE</literal> pragma affects the specialised verison of the
+The <literal>INLINE</literal> pragma affects the specialised version of the
function (only), and applies even if the function is recursive. The motivating
example is this:
<programlisting>
<listitem>
<para>
- The definition of (say) <function>build</function> in <filename>GHC/Base.lhs</filename> looks llike this:
+ The definition of (say) <function>build</function> in <filename>GHC/Base.lhs</filename> looks like this:
<programlisting>
build :: forall a. (forall b. (a -> b -> b) -> b -> b) -> [a]
<sect1 id="special-ids">
<title>Special built-in functions</title>
-<para>GHC has a few built-in funcions with special behaviour. These
+<para>GHC has a few built-in functions with special behaviour. These
are now described in the module <ulink
url="../libraries/base/GHC-Prim.html"><literal>GHC.Prim</literal></ulink>
in the library documentation.</para>
op2 :: a -> Bool
op2 {| p :*: q |} (x :*: y) = False
</programlisting>
-(The reason for this restriction is that we gather all the equations for a particular type consructor
+(The reason for this restriction is that we gather all the equations for a particular type constructor
into a single generic instance declaration.)
</para>
</listitem>
inside a list.
</para>
<para>
-This restriction is an implementation restriction: we just havn't got around to
+This restriction is an implementation restriction: we just haven't got around to
implementing the necessary bidirectional maps over arbitrary type constructors.
It would be relatively easy to add specific type constructors, such as Maybe and list,
to the ones that are allowed.</para>
projects / ghc-hetmet.git / commitdiff