<listitem>
<para>New commands: <literal>:browse</literal>, <literal>:set
args</literal>, <literal>:set prog</literal>, <literal>:show
- binadings</literal>, and <literal>:show modules</literal> (see
+ bindings</literal>, and <literal>:show modules</literal> (see
<xref linkend="ghci-commands">).</para>
</listitem>
<listitem>
<programlisting>
main = print (array (1,1) [(1,2), (1,3)])</programlisting>
-GHC's implemetation of <literal>array</literal> takes the value of an
+GHC's implementation of <literal>array</literal> takes the value of an
array slot from the last (index,value) pair in the list, and does no
checking for duplicates. The reason for this is efficiency, pure and simple.
</para>
<indexterm><primary><option>-ddump-simpl</option></primary></indexterm>
</term>
<listitem>
- <para>simplifer output (Core-to-Core passes)</para>
+ <para>simplifier output (Core-to-Core passes)</para>
</listitem>
</varlistentry>
fromInt.t4GS = (fromInt{-r3JX-} _4) d.Num.t4Gt
--# The `+' class method (Unique: r3JH) selects the addition code
---# from a `Num' dictionary (now an explicit lamba'd argument).
+--# from a `Num' dictionary (now an explicit lambda'd argument).
--# Because Core is 2nd-order lambda-calculus, type applications
--# and lambdas (/\) are explicit. So `+' is first applied to a
--# type (`_4'), then to a dictionary, yielding the actual addition
</listitem>
</itemizedlist>
- <para>Both ways require you to bootrap from intermediate
+ <para>Both ways require you to bootstrap from intermediate
<literal>HC</literal> files: these are the stylised C files
generated by GHC when it compiles Haskell source. Basically
the idea is to take the HC files for GHC itself to the target
descriptor (gotten from <literal>Posix.handleToFd</literal>)
before the first read, but this doesn't work on FreeBSD
(although rumour has it that recent versions of FreeBSD
- changed the behavour to match other OSs). A workaround for
+ changed the behaviour to match other OSs). A workaround for
all systems is to open the FIFO for writing yourself, before
(or at the same time as) opening it for reading.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>If I explicitely set the buffering on a Handle to
+ <term>If I explicitly set the buffering on a Handle to
"NoBuffering" I'm not able to enter EOF by typing
"Ctrl-D".</term>
<literal>main()</literal>, which arranges to invoke
<literal>Main.main</literal> in the Haskell program. However,
you might want to link some Haskell code into a program which
- has a main function written in another languagem, say C. In
+ has a main function written in another language, say C. In
order to do this, you have to initialize the Haskell runtime
system explicitly.</para>
</programlisting>
When compiling this module, GHC will generate a C file that includes
the specified <option>-#include</option>. However, GHC
-<emphasis>disables</emphasis> cross-module inlinding for such foreign
+<emphasis>disables</emphasis> cross-module inlining for such foreign
calls, because it doesn't transport the <option>-#include</option>
information across module boundaries. (There is no fundamental reason for this;
it was just tiresome to implement. The wrapper, which unboxes the arguments
<listitem>
<para>Useful for short-term allocation when the allocation
is intended to scope over a given <literal>IO</literal>
- compuatation. This kind of allocation is commonly used
+ computation. This kind of allocation is commonly used
when marshalling data to and from FFI functions.</para>
<para>In GHC, <literal>alloca</literal> is implemented
<para>If all else fails, then you need to resort to
<literal>Foreign.malloc</literal> and
<literal>Foreign.free</literal>. These are just wrappers
- around the C funcitons of the same name, and their
+ around the C functions of the same name, and their
efficiency will depend ultimately on the implementations
of these functions in your platform's C library. We
usually find <literal>malloc</literal> and
</varlistentry>
<varlistentry>
- <term><literal>Foreign.Marhsal.Pool</literal></term>
+ <term><literal>Foreign.Marshal.Pool</literal></term>
<listitem>
<para>Pools are currently implemented using
<literal>malloc/free</literal>, so while they might be a
more convenient way to structure your memory allocation
than using one of the other forms of allocation, they
won't be any more efficient. We do plan to provide an
- improved-performance implementaiton of Pools in the
+ improved-performance implementation of Pools in the
future, however.</para>
</listitem>
</varlistentry>
</row>
<row>
<entry><option>-no-hs-main</option></entry>
- <entry>Don't asssume this program contains <literal>main</literal></entry>
+ <entry>Don't assume this program contains <literal>main</literal></entry>
<entry>static</entry>
<entry>-</entry>
</row>
</footnote>
is GHC's interactive environment, in which Haskell expressions can
be interactively evaluated and programs can be interpreted. If
- you're famililar with <ulink url="http://www.haskell.org/hugs/">Hugs</ulink><indexterm><primary>Hugs</primary>
+ you're familiar with <ulink url="http://www.haskell.org/hugs/">Hugs</ulink><indexterm><primary>Hugs</primary>
</indexterm>, then you'll be right at home with GHCi. However, GHCi
also has support for interactively loading compiled code, as well as
supporting all<footnote><para>except <literal>foreign export</literal>, at the moment</para>
</sect2>
</sect1>
- <sect1 id="ghci-invokation">
+ <sect1 id="ghci-invocation">
<title>Invoking GHCi</title>
<indexterm><primary>invoking</primary><secondary>GHCi</secondary></indexterm>
<indexterm><primary><option>––interactive</option></primary></indexterm>
</listitem>
<listitem>
<para>the standard library search path for your system,
- which on some systems may be overriden by setting the
+ which on some systems may be overridden by setting the
<literal>LD_LIBRARY_PATH</literal> environment
variable.</para>
</listitem>
</programlisting>
<para>
-The semantics should be clear enough. The qualifers are matched in order.
+The semantics should be clear enough. The qualifiers are matched in order.
For a <literal><-</literal> qualifier, which I call a pattern guard, the
right hand side is evaluated and matched against the pattern on the left.
If the match fails then the whole guard fails and the next equation is
<title>Liberalised type synonyms</title>
<para>
-Type synonmys are like macros at the type level, and
+Type synonyms are like macros at the type level, and
GHC does validity checking on types <emphasis>only after expanding type synonyms</emphasis>.
That means that GHC can be very much more liberal about type synonyms than Haskell 98:
<itemizedlist>
foo :: Generic Id []
</programlisting>
-After epxanding the synonym, <literal>foo</literal> has the legal (in GHC) type:
+After expanding the synonym, <literal>foo</literal> has the legal (in GHC) type:
<programlisting>
foo :: forall x. x -> [x]
</programlisting>
<para>
<emphasis>All of the class type variables must be reachable (in the sense
mentioned in <xref linkend="type-restrictions"/>)
-from the free varibles of each method type
+from the free variables of each method type
</emphasis>. For example:
<para>
Note
that the reachability condition is weaker than saying that <literal>a</literal> is
-functionally dependendent on a type variable free in
+functionally dependent on a type variable free in
<literal>type</literal> (see <xref
linkend="functional-dependencies"/>). The reason for this is there
might be a "hidden" dependency, in a superclass perhaps. So
f x = op x
</programlisting>
From the RHS of f we get the constraint <literal>C [b]</literal>. But
-GHC does not commit to the second instance declaration, because in a paricular
+GHC does not commit to the second instance declaration, because in a particular
call of f, b might be instantiate to Int, so the first instance declaration
would be appropriate. So GHC rejects the program. If you add <option>-fallow-incoherent-instances</option>
GHC will instead silently pick the second instance, without complaining about
<sect2 id="implicit-parameters">
<title>Implicit parameters</title>
-<para> Implicit paramters are implemented as described in
+<para> Implicit parameters are implemented as described in
"Implicit parameters: dynamic scoping with static types",
J Lewis, MB Shields, E Meijer, J Launchbury,
27th ACM Symposium on Principles of Programming Languages (POPL'00),
</para>
<itemizedlist>
<listitem> <para> distributing a supply of unique names </para> </listitem>
-<listitem> <para> distributing a suppply of random numbers </para> </listitem>
+<listitem> <para> distributing a supply of random numbers </para> </listitem>
<listitem> <para> distributing an oracle (as in QuickCheck) </para> </listitem>
</itemizedlist>
</para>
<para>
The functions <literal>f2</literal> and <literal>g2</literal> have rank-2 types;
-the <literal>forall</literal> is on the left of a function arrrow. As <literal>g2</literal>
+the <literal>forall</literal> is on the left of a function arrow. As <literal>g2</literal>
shows, the polymorphic type on the left of the function arrow can be overloaded.
</para>
<para>
<title>Type inference</title>
<para>
-In general, type inference for arbitrary-rank types is undecideable.
+In general, type inference for arbitrary-rank types is undecidable.
GHC uses an algorithm proposed by Odersky and Laufer ("Putting type annotations to work", POPL'96)
to get a decidable algorithm by requiring some help from the programmer.
We do not yet have a formal specification of "some help" but the rule is this:
<listitem>
<para>
A pattern type signature can be on an arbitrary sub-pattern, not
-ust on a variable:
+just on a variable:
<programlisting>
<itemizedlist>
<listitem><para>
Data type declarations have a 'where' form, as exemplified above. The type signature of
-each constructor is independent, and is implicitly univerally quantified as usual. Unlike a normal
+each constructor is independent, and is implicitly universally quantified as usual. Unlike a normal
Haskell data type declaration, the type variable(s) in the "<literal>data Term a where</literal>" header
have no scope. Indeed, one can write a kind signature instead:
<programlisting>
{-# DEPRECATED f, C, T "Don't use these" #-}
</programlisting>
<para>When you compile any module that imports and uses any
- of the specifed entities, GHC will print the specified
+ of the specified entities, GHC will print the specified
message.</para>
</listitem>
</itemizedlist>
The normal unfolding machinery will then be very keen to
inline it.</para>
- <para>Syntactially, an <literal>INLINE</literal> pragma for a
+ <para>Syntactically, an <literal>INLINE</literal> pragma for a
function can be put anywhere its type signature could be
put.</para>
number</emphasis>; the phase number decreases towards zero.
If you use <option>-dverbose-core2core</option> you'll see the
sequence of phase numbers for successive runs of the
- simpifier. In an INLINE pragma you can optionally specify a
+ simplifier. In an INLINE pragma you can optionally specify a
phase number, thus:</para>
<itemizedlist>
<sect1 id="rewrite-rules">
<title>Rewrite rules
-<indexterm><primary>RULES pagma</primary></indexterm>
+<indexterm><primary>RULES pragma</primary></indexterm>
<indexterm><primary>pragma, RULES</primary></indexterm>
<indexterm><primary>rewrite rules</primary></indexterm></title>
<para>
GHC makes absolutely no attempt to verify that the LHS and RHS
-of a rule have the same meaning. That is undecideable in general, and
+of a rule have the same meaning. That is undecidable in general, and
infeasible in most interesting cases. The responsibility is entirely the programmer's!
</para>
for matching a rule LHS with an expression. It seeks a substitution
which makes the LHS and expression syntactically equal modulo alpha
conversion. The pattern (rule), but not the expression, is eta-expanded if
-necessary. (Eta-expanding the epression can lead to laziness bugs.)
+necessary. (Eta-expanding the expression can lead to laziness bugs.)
But not beta conversion (that's called higher-order matching).
</para>
<listitem>
<para>
- The defintion 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 llike this:
<programlisting>
build :: forall a. (forall b. (a -> b -> b) -> b -> b) -> [a]
f x = ({-# CORE "foo" #-} show) ({-# CORE "bar" #-} x)
</programlisting>
- Sematically, this is equivalent to:
+ Semantically, this is equivalent to:
<programlisting>
g x = show x
<para>
It is OK to put GHC tree in a directory whose path involves spaces. However,
don't do this if you use want to use GHC with the Cygwin tools,
-because Cygwin can get confused when this happpens.
+because Cygwin can get confused when this happens.
We havn't quite got to the bottom of this, but so far as we know it's not
a problem with GHC itself. Nevertheless, just to keep life simple we usually
put GHC in a place with a space-free path.
{-# SCC "name" #-} <expression>
</programlisting>
- <para>where <literal>"name"</literal> is an aribrary string,
+ <para>where <literal>"name"</literal> is an arbitrary string,
that will become the name of your cost centre as it appears
in the profiling output, and
<literal><expression></literal> is any Haskell
over time. This is useful for detecting the causes of
<firstterm>space leaks</firstterm>, when your program holds on to
more memory at run-time that it needs to. Space leaks lead to
- longer run-times due to heavy garbage collector ativity, and may
+ longer run-times due to heavy garbage collector activity, and may
even cause the program to run out of memory altogether.</para>
<para>To generate a heap profile from your program:</para>
<para>The definition of retainers is designed to reflect a
common cause of space leaks: a large structure is retained by
an unevaluated computation, and will be released once the
- compuation is forced. A good example is looking up a value in
+ computation is forced. A good example is looking up a value in
a finite map, where unless the lookup is forced in a timely
manner the unevaluated lookup will cause the whole mapping to
be retained. These kind of space leaks can often be
</screen>
<para>RTS options taken from the <envar>GHCRTS</envar> environment
- variable can be overriden by options given on the command
+ variable can be overridden by options given on the command
line.</para>
</sect2>
will not get confused.</para>
<para>In batch compilation mode, the name of the object file can
- also be overriden using the <option>-o</option> option, and the
+ also be overridden using the <option>-o</option> option, and the
name of the interface file can be specified directly using the
<option>-ohi</option> option.</para>
</sect2>
it used when it last compiled the file. If the source file's
modification date is earlier than the <filename>.o</filename>
file's date (i.e. the source hasn't changed since the file was
- last compiled), and the reompilation checking is on, GHC will be
+ last compiled), and the recompilation checking is on, GHC will be
clever. It compares the version numbers on the things it needs
this time with the version numbers on the things it needed last
time (gleaned from the interface file of the module being
</programlisting>
In a <emphasis>source</emphasis> program
this would declare TA to have no constructors (a GHC extension: see <xref linkend="nullary-types"/>),
- but in an hi-boot file it means "I don't know or care what the construtors are".
+ but in an hi-boot file it means "I don't know or care what the constructors are".
This is the most common form of data type declaration, because it's easy to get right.</para>
<para>
You <emphasis>can</emphasis> also write out the constructors but, if you do so, you must write
<listitem>
<para>GHC doesn't have to be restarted for each compilation,
which means it can cache information between compilations.
- Compiling a muli-module program with <literal>ghc
+ Compiling a multi-module program with <literal>ghc
––make</literal> can be up to twice as fast as
running <literal>ghc</literal> individually on each source
file.</para>
pragma (see <xref linkend="source-file-options"/>).</para>
<para>If the program needs to be linked with additional objects
- (say, some auxilliary C code), then the object files can be
+ (say, some auxiliary C code), then the object files can be
given on the command line and GHC will include them when linking
the executable.</para>
only)</primary></indexterm> Means to pass the like-named
option to GCC; it says to use the Version 8 SPARC
instructions, notably integer multiply and divide. The
- similiar <option>-m*</option> GCC options for SPARC also
+ similar <option>-m*</option> GCC options for SPARC also
work, actually.</para>
</listitem>
</varlistentry>
<para>GHC can also read in External Core files as source; just give the <literal>.hcr</literal> file on
the command line, instead of the <literal>.hs</literal> or <literal>.lhs</literal> Haskell source.
-A current infelicity is that you need to give teh <literal>-fglasgow-exts</literal> flag too, because
+A current infelicity is that you need to give the <literal>-fglasgow-exts</literal> flag too, because
ordinary Haskell 98, when translated to External Core, uses things like rank-2 types.</para>
</sect1>
<para>This section describes other program(s) which we distribute,
that help with the Great Haskell Programming Task.</para>
-<!-- comment: hasktags documentation losely based on that for hstags -->
+<!-- comment: hasktags documentation loosely based on that for hstags -->
<sect1 id ="hasktags">
<title>Ctags and Etags for Haskell: <command>hasktags</command></title>
<para>This will find all haskell source files in the current directory and below, and create tags files indexing them in the current directory.</para>
<para><command>hasktags</command> is a simple program that uses simple
- parsing rules to find definitions of functions, constructors, and types. It isn't guranteed to find everything, and will sometimes create false index entries, but it usually gets the job done fairly well. In particular, at present, functions are only indexed if a type signature is given for them.</para>
+ parsing rules to find definitions of functions, constructors, and types. It isn't guaranteed to find everything, and will sometimes create false index entries, but it usually gets the job done fairly well. In particular, at present, functions are only indexed if a type signature is given for them.</para>
<para>Before hasktags, there used to be <command>fptags</command> and <command>hstags</command>, which did essentially the same job, however neither of these seem to be maintained any more.</para>
source. They are useful for making a <literal>#let</literal>-like
macro whose expansion uses other <literal>#let</literal> macros.
Plain <literal>#let</literal> prepends <literal>hsc_</literal>
- to the macro name and wraps the defininition in a
+ to the macro name and wraps the definition in a
<literal>printf</literal> call.</para>
</sect2>
projects / ghc-hetmet.git / commitdiff