Commit 7db602a0 authored by rrt's avatar rrt

[project @ 2000-01-24 16:47:24 by rrt]

Changed double quotes to “ and ”. Improvements to Windows
installation instructions.
parent 17a29073
......@@ -13,7 +13,7 @@
<ItemizedList>
<ListItem>
<Para>
``Finalise'' is now spelt ``finalize'' in all function names.
&ldquo;Finalise&rdquo; is now spelt &ldquo;finalize&rdquo; in all function names.
</Para>
</ListItem>
......
......@@ -390,10 +390,10 @@ when even <Option>-dverbose-simpl</Option> doesn't cut it.
<Para>
<IndexTerm><Primary>-dppr-user option</Primary></IndexTerm>
<IndexTerm><Primary>-dppr-debug option</Primary></IndexTerm>
Debugging output is in one of several ``styles.'' Take the printing
of types, for example. In the ``user'' style, the compiler's internal
Debugging output is in one of several &ldquo;styles.&rdquo; Take the printing
of types, for example. In the &ldquo;user&rdquo; style, the compiler's internal
ideas about types are presented in Haskell source-level syntax,
insofar as possible. In the ``debug'' style (which is the default for
insofar as possible. In the &ldquo;debug&rdquo; style (which is the default for
debugging output), the types are printed in with
explicit foralls, and variables have their unique-id attached (so you
can check for things that look the same but aren't).
......@@ -415,7 +415,7 @@ of transformation too place. If you add <Option>-dppr-debug</Option> you get mo
<ListItem>
<Para>
<IndexTerm><Primary>-ddump-raw-asm option</Primary></IndexTerm>
Dump out the assembly-language stuff, before the ``mangler'' gets it.
Dump out the assembly-language stuff, before the &ldquo;mangler&rdquo; gets it.
</Para>
</ListItem>
</VarListEntry>
......@@ -522,16 +522,16 @@ skip2 m = m : skip2 (m+2)
<Para>
Before we jump in, a word about names of things. Within GHC,
variables, type constructors, etc., are identified by their
``Uniques.'' These are of the form `letter' plus `number' (both
&ldquo;Uniques.&rdquo; These are of the form `letter' plus `number' (both
loosely interpreted). The `letter' gives some idea of where the
Unique came from; e.g., <Literal>&lowbar;</Literal> means ``built-in type variable'';
<Literal>t</Literal> means ``from the typechecker''; <Literal>s</Literal> means ``from the
simplifier''; and so on. The `number' is printed fairly compactly in
Unique came from; e.g., <Literal>&lowbar;</Literal> means &ldquo;built-in type variable&rdquo;;
<Literal>t</Literal> means &ldquo;from the typechecker&rdquo;; <Literal>s</Literal> means &ldquo;from the
simplifier&rdquo;; and so on. The `number' is printed fairly compactly in
a `base-62' format, which everyone hates except me (WDP).
</Para>
<Para>
Remember, everything has a ``Unique'' and it is usually printed out
Remember, everything has a &ldquo;Unique&rdquo; and it is usually printed out
when debugging, in some form or another. So here we go&hellip;
</Para>
......@@ -610,7 +610,7 @@ Main.skip2{-r1L6-} =
</Para>
<Para>
(``It's just a simple functional language'' is an unregisterised
(&ldquo;It's just a simple functional language&rdquo; is an unregisterised
trademark of Peyton Jones Enterprises, plc.)
</Para>
......
......@@ -10,9 +10,9 @@ the language. To use them, you'll need to give a <Option>-fglasgow-exts</Option
Virtually all of the Glasgow extensions serve to give you access to
the underlying facilities with which we implement Haskell. Thus, you
can get at the Raw Iron, if you are willing to write some non-standard
code at a more primitive level. You need not be ``stuck'' on
code at a more primitive level. You need not be &ldquo;stuck&rdquo; on
performance because of the implementation costs of Haskell's
``high-level'' features&mdash;you can always code ``under'' them. In an
&ldquo;high-level&rdquo; features&mdash;you can always code &ldquo;under&rdquo; them. In an
extreme case, you can write all your time-critical code in C, and then
just glue it together with Haskell!
</Para>
......@@ -29,7 +29,7 @@ Executive summary of our extensions:
<ListItem>
<Para>
You can get right down to the raw machine types and operations;
included in this are ``primitive arrays'' (direct access to Big Wads
included in this are &ldquo;primitive arrays&rdquo; (direct access to Big Wads
of Bytes). Please see <XRef LinkEnd="glasgow-unboxed"> and following.
</Para>
</ListItem>
......@@ -113,8 +113,8 @@ Details in <XRef LinkEnd="rewrite-rules">.
<Para>
Before you get too carried away working at the lowest level (e.g.,
sloshing <Literal>MutableByteArray&num;</Literal>s around your program), you may wish to
check if there are system libraries that provide a ``Haskellised
veneer'' over the features you want. See <XRef LinkEnd="ghc-prelude">.
check if there are system libraries that provide a &ldquo;Haskellised
veneer&rdquo; over the features you want. See <XRef LinkEnd="ghc-prelude">.
</Para>
<Sect1 id="glasgow-unboxed">
......@@ -126,7 +126,7 @@ veneer'' over the features you want. See <XRef LinkEnd="ghc-prelude">.
</Para>
<Para>
These types correspond to the ``raw machine'' types you would use in
These types correspond to the &ldquo;raw machine&rdquo; types you would use in
C: <Literal>Int&num;</Literal> (long int), <Literal>Double&num;</Literal> (double), <Literal>Addr&num;</Literal> (void *), etc. The
<Emphasis>primitive operations</Emphasis> (PrimOps) on these types are what you
might expect; e.g., <Literal>(+&num;)</Literal> is addition on <Literal>Int&num;</Literal>s, and is the
......@@ -149,7 +149,7 @@ results. Even worse, the unboxed value might be larger than a pointer
<Para>
Nevertheless, A numerically-intensive program using unboxed types can
go a <Emphasis>lot</Emphasis> faster than its ``standard'' counterpart&mdash;we saw a
go a <Emphasis>lot</Emphasis> faster than its &ldquo;standard&rdquo; counterpart&mdash;we saw a
threefold speedup on one example.
</Para>
......@@ -171,7 +171,7 @@ operations on them.
<Para>
This monad underlies our implementation of arrays, mutable and
immutable, and our implementation of I/O, including ``C calls''.
immutable, and our implementation of I/O, including &ldquo;C calls&rdquo;.
</Para>
<Para>
......@@ -211,7 +211,7 @@ Second, it distinguishes between&hellip;
<Term>Immutable:</Term>
<ListItem>
<Para>
Arrays that do not change (as with ``standard'' Haskell arrays); you
Arrays that do not change (as with &ldquo;standard&rdquo; Haskell arrays); you
can only read from them. Obviously, they do not need the care and
attention of the state-transformer monad.
</Para>
......@@ -221,29 +221,29 @@ attention of the state-transformer monad.
<Term>Mutable:</Term>
<ListItem>
<Para>
Arrays that may be changed or ``mutated.'' All the operations on them
Arrays that may be changed or &ldquo;mutated.&rdquo; All the operations on them
live within the state-transformer monad and the updates happen
<Emphasis>in-place</Emphasis>.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``Static'' (in C land):</Term>
<Term>&ldquo;Static&rdquo; (in C land):</Term>
<ListItem>
<Para>
A C routine may pass an <Literal>Addr&num;</Literal> pointer back into Haskell land. There
are then primitive operations with which you may merrily grab values
over in C land, by indexing off the ``static'' pointer.
over in C land, by indexing off the &ldquo;static&rdquo; pointer.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``Stable'' pointers:</Term>
<Term>&ldquo;Stable&rdquo; pointers:</Term>
<ListItem>
<Para>
If, for some reason, you wish to hand a Haskell pointer (i.e.,
<Emphasis>not</Emphasis> an unboxed value) to a C routine, you first make the
pointer ``stable,'' so that the garbage collector won't forget that it
pointer &ldquo;stable,&rdquo; so that the garbage collector won't forget that it
exists. That is, GHC provides a safe way to pass Haskell pointers to
C.
</Para>
......@@ -254,14 +254,14 @@ Please see <XRef LinkEnd="glasgow-stablePtrs"> for more details.
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``Foreign objects'':</Term>
<Term>&ldquo;Foreign objects&rdquo;:</Term>
<ListItem>
<Para>
A ``foreign object'' is a safe way to pass an external object (a
A &ldquo;foreign object&rdquo; is a safe way to pass an external object (a
C-allocated pointer, say) to Haskell and have Haskell do the Right
Thing when it no longer references the object. So, for example, C
could pass a large bitmap over to Haskell and say ``please free this
memory when you're done with it.''
could pass a large bitmap over to Haskell and say &ldquo;please free this
memory when you're done with it.&rdquo;
</Para>
<Para>
......@@ -273,8 +273,8 @@ Please see <XRef LinkEnd="glasgow-foreignObjs"> for more details.
</Para>
<Para>
The libraries section gives more details on all these ``primitive
array'' types and the operations on them, <XRef LinkEnd="ghc-prelude">. Some of these extensions
The libraries section gives more details on all these &ldquo;primitive
array&rdquo; types and the operations on them, <XRef LinkEnd="ghc-prelude">. Some of these extensions
are also supported by Hugs, and the supporting libraries are described
in the <ULink
URL="libs.html"
......@@ -326,7 +326,7 @@ is to provide a Haskell wrapper:
<ProgramListing>
fooH :: Char -&#62; Int -&#62; Double -&#62; Word -&#62; IO Double
fooH c i d w = _ccall_ fooC (``stdin''::Addr) c i d w
fooH c i d w = _ccall_ fooC (&ldquo;stdin&rdquo;::Addr) c i d w
</ProgramListing>
</Para>
......@@ -350,7 +350,7 @@ import Addr
import CString
oldGetEnv name
= _casm_ ``%r = getenv((char *) %0);'' name &#62;&#62;= \ litstring -&#62;
= _casm_ &ldquo;%r = getenv((char *) %0);&rdquo; name &#62;&#62;= \ litstring -&#62;
return (
if (litstring == nullAddr) then
Left ("Fail:oldGetEnv:"++name)
......@@ -363,7 +363,7 @@ oldGetEnv name
<Para>
The first literal-literal argument to a <Function>&lowbar;casm&lowbar;</Function> is like a <Function>printf</Function>
format: <Literal>&percnt;r</Literal> is replaced with the ``result,'' <Literal>&percnt;0</Literal>&ndash;<Literal>&percnt;n-1</Literal> are
format: <Literal>&percnt;r</Literal> is replaced with the &ldquo;result,&rdquo; <Literal>&percnt;0</Literal>&ndash;<Literal>&percnt;n-1</Literal> are
replaced with the 1st&ndash;nth arguments. As you can see above, it is an
easy way to do simple C&nbsp;casting. Everything said about <Function>&lowbar;ccall&lowbar;</Function> goes
for <Function>&lowbar;casm&lowbar;</Function> as well.
......@@ -409,7 +409,7 @@ from the <Function>&lowbar;casm&lowbar;</Function> construct itself. Indeed, we'
<ProgramListing>
fooH :: Char -&#62; Int -&#62; Double -&#62; Word -&#62; IO Double
fooH c i d w = _ccall_ fooC (``stdin''::Addr) c i d w
fooH c i d w = _ccall_ fooC (&ldquo;stdin&rdquo;::Addr) c i d w
</ProgramListing>
</Para>
......@@ -562,7 +562,7 @@ solid code. You're crazy not to do it.
</Sect2>
<Sect2 id="glasgow-stablePtrs">
<Title>Subverting automatic unboxing with ``stable pointers''
<Title>Subverting automatic unboxing with &ldquo;stable pointers&rdquo;
</Title>
<Para>
......@@ -601,8 +601,8 @@ to boxed objects are not <Emphasis>stable</Emphasis>.
</Para>
<Para>
It is possible to subvert the unboxing process by creating a ``stable
pointer'' to a value and passing the stable pointer instead. For
It is possible to subvert the unboxing process by creating a &ldquo;stable
pointer&rdquo; to a value and passing the stable pointer instead. For
example, to pass/return an integer lazily to C functions <Function>storeC</Function> and
<Function>fetchC</Function> might write:
</Para>
......@@ -769,7 +769,7 @@ atan2d y x = unsafePerformIO (_ccall_ atan2d y x)
sincosd :: Double -&#62; (Double, Double)
sincosd x = unsafePerformIO $ do
da &#60;- newDoubleArray (0, 1)
_casm_ ``sincosd( %0, &amp;((double *)%1[0]), &amp;((double *)%1[1]) );'' x da
_casm_ &ldquo;sincosd( %0, &amp;((double *)%1[0]), &amp;((double *)%1[1]) );&rdquo; x da
s &#60;- readDoubleArray da 0
c &#60;- readDoubleArray da 1
return (s, c)
......@@ -825,7 +825,7 @@ trace string expr
((_ccall_ PostTraceHook sTDERR{-msg-}):: IO ()) &#62;&#62;
return expr )
where
sTDERR = (``stderr'' :: Addr)
sTDERR = (&ldquo;stderr&rdquo; :: Addr)
</ProgramListing>
......@@ -841,7 +841,7 @@ useful in debugging code.)
</Sect2>
<Sect2 id="ccall-gotchas">
<Title>C-calling ``gotchas'' checklist
<Title>C-calling &ldquo;gotchas&rdquo; checklist
</Title>
<Para>
......@@ -2851,7 +2851,7 @@ also OK to say:
<ListItem>
<Para>
To avoid ambiguity, the type after the ``<Literal>::</Literal>'' in a result
To avoid ambiguity, the type after the &ldquo;<Literal>::</Literal>&rdquo; in a result
pattern signature on a lambda or <Literal>case</Literal> must be atomic (i.e. a single
token or a parenthesised type of some sort). To see why,
consider how one would parse this:
......@@ -2972,8 +2972,8 @@ but they might affect the efficiency of the generated code.
<IndexTerm><Primary>pragma, INLINE</Primary></IndexTerm></Title>
<Para>
GHC (with <Option>-O</Option>, as always) tries to inline (or ``unfold'')
functions/values that are ``small enough,'' thus avoiding the call
GHC (with <Option>-O</Option>, as always) tries to inline (or &ldquo;unfold&rdquo;)
functions/values that are &ldquo;small enough,&rdquo; thus avoiding the call
overhead and possibly exposing other more-wonderful optimisations.
</Para>
......@@ -2983,7 +2983,7 @@ interface files.
</Para>
<Para>
Normally, if GHC decides a function is ``too expensive'' to inline, it
Normally, if GHC decides a function is &ldquo;too expensive&rdquo; to inline, it
will not do so, nor will it export that unfolding for other modules to
use.
</Para>
......@@ -3006,7 +3006,7 @@ to stick the code through HBC&mdash;it doesn't like <Literal>INLINE</Literal> pr
<Para>
The major effect of an <Literal>INLINE</Literal> pragma is to declare a function's
``cost'' to be very low. The normal unfolding machinery will then be
&ldquo;cost&rdquo; to be very low. The normal unfolding machinery will then be
very keen to inline it.
</Para>
......@@ -3719,7 +3719,7 @@ If you add <Option>-dppr-debug</Option> you get a more detailed listing.
</ProgramListing>
Notice the <Literal>INLINE</Literal>! That prevents <Literal>(:)</Literal> from being inlined when compiling
<Literal>PrelBase</Literal>, so that an importing module will ``see'' the <Literal>(:)</Literal>, and can
<Literal>PrelBase</Literal>, so that an importing module will &ldquo;see&rdquo; the <Literal>(:)</Literal>, and can
match it on the LHS of a rule. <Literal>INLINE</Literal> prevents any inlining happening
in the RHS of the <Literal>INLINE</Literal> thing. I regret the delicacy of this.
......
......@@ -20,7 +20,7 @@ be of interest.)
</Para>
<Sect1 id="wrong-compiler">
<Title>When the compiler ``does the wrong thing''
<Title>When the compiler &ldquo;does the wrong thing&rdquo;
</Title>
<Para>
......@@ -32,7 +32,7 @@ be of interest.)
<VariableList>
<VarListEntry>
<Term>``Help! The compiler crashed (or `panic'd)!''</Term>
<Term>&ldquo;Help! The compiler crashed (or `panic'd)!&rdquo;</Term>
<ListItem>
<Para>
These events are <Emphasis>always</Emphasis> bugs in the GHC system&mdash;please report them.
......@@ -40,7 +40,7 @@ These events are <Emphasis>always</Emphasis> bugs in the GHC system&mdash;please
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``The compiler ran out of heap (or stack) when compiling itself!''</Term>
<Term>&ldquo;The compiler ran out of heap (or stack) when compiling itself!&rdquo;</Term>
<ListItem>
<Para>
It happens. We try to supply reasonable <Option>-H&lt;n&gt;</Option> flags for
......@@ -61,15 +61,15 @@ heap.
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``The compiler died with a pattern-matching error.''</Term>
<Term>&ldquo;The compiler died with a pattern-matching error.&rdquo;</Term>
<ListItem>
<Para>
This is a bug just as surely as a ``panic.'' Please report it.
This is a bug just as surely as a &ldquo;panic.&rdquo; Please report it.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``This is a terrible error message.''</Term>
<Term>&ldquo;This is a terrible error message.&rdquo;</Term>
<ListItem>
<Para>
If you think that GHC could have produced a better error message,
......@@ -78,7 +78,7 @@ please report it as a bug.
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``What about these `trace' messages from GHC?''</Term>
<Term>&ldquo;What about these `trace' messages from GHC?&rdquo;</Term>
<ListItem>
<Para>
Almost surely not a problem. About some specific cases&hellip;
......@@ -96,7 +96,7 @@ turning on the <Option>-fshow-simplifier-progress</Option>
</Para>
<Para>
If the simplifier definitely seems to be ``looping,'' please report
If the simplifier definitely seems to be &ldquo;looping,&rdquo; please report
it.
</Para>
</ListItem>
......@@ -106,10 +106,10 @@ it.
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``What about this warning from the C compiler?''</Term>
<Term>&ldquo;What about this warning from the C compiler?&rdquo;</Term>
<ListItem>
<Para>
For example: ``&hellip;warning: `Foo' declared `static' but never defined.''
For example: &ldquo;&hellip;warning: `Foo' declared `static' but never defined.&rdquo;
Unsightly, but shouldn't be a problem.
</Para>
</ListItem>
......@@ -132,11 +132,11 @@ running programs compiled using unstable interfaces.
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``I think GHC is producing incorrect code'':</Term>
<Term>&ldquo;I think GHC is producing incorrect code&rdquo;:</Term>
<ListItem>
<Para>
Unlikely :-) A useful be-more-paranoid option to give to GHC is
<Option>-dcore-lint</Option><IndexTerm><Primary>-dcore-lint option</Primary></IndexTerm>; this causes a ``lint''
<Option>-dcore-lint</Option><IndexTerm><Primary>-dcore-lint option</Primary></IndexTerm>; this causes a &ldquo;lint&rdquo;
pass to check for errors (notably type errors) after each Core-to-Core
transformation pass. We run with <Option>-dcore-lint</Option> on all the time; it
costs about 5&percnt; in compile time.
......@@ -144,7 +144,7 @@ costs about 5&percnt; in compile time.
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``Why did I get a link error?''</Term>
<Term>&ldquo;Why did I get a link error?&rdquo;</Term>
<ListItem>
<Para>
If the linker complains about not finding <Literal>&lowbar;&lt;something&gt;&lowbar;fast</Literal>, then
......@@ -154,7 +154,7 @@ proper dependency order.
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``What's a `consistency error'?''</Term>
<Term>&ldquo;What's a `consistency error'?&rdquo;</Term>
<ListItem>
<Para>
(These are reported just after linking your program.)
......@@ -176,11 +176,11 @@ tags/strings in your object files. They must all be the same!
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``Is this line number right?''</Term>
<Term>&ldquo;Is this line number right?&rdquo;</Term>
<ListItem>
<Para>
On this score, GHC usually does pretty well, especially
if you ``allow'' it to be off by one or two. In the case of an
if you &ldquo;allow&rdquo; it to be off by one or two. In the case of an
instance or class declaration, the line number
may only point you to the declaration, not to a specific method.
</Para>
......@@ -196,7 +196,7 @@ Please report line-number errors that you find particularly unhelpful.
</Sect1>
<Sect1 id="wrong-compilee">
<Title>When your program ``does the wrong thing''
<Title>When your program &ldquo;does the wrong thing&rdquo;
</Title>
<Para>
......@@ -212,7 +212,7 @@ please see <XRef LinkEnd="sooner-faster-quicker">).
<VariableList>
<VarListEntry>
<Term>``Help! My program crashed!''</Term>
<Term>&ldquo;Help! My program crashed!&rdquo;</Term>
<ListItem>
<Para>
(e.g., a `segmentation fault' or `core dumped')
......@@ -231,7 +231,7 @@ case these <Emphasis>must</Emphasis> be correct with respect to the module sourc
For example, if an interface is lying about the type of an imported
value then GHC may well generate duff code for the importing module.
<Emphasis>This applies to pragmas inside interfaces too!</Emphasis> If the pragma is
lying (e.g., about the ``arity'' of a value), then duff code may result.
lying (e.g., about the &ldquo;arity&rdquo; of a value), then duff code may result.
Furthermore, arities may change even if types do not.
</Para>
......@@ -281,7 +281,7 @@ GHC-compiled program, please see <XRef LinkEnd="hard-core-debug">.
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``My program entered an `absent' argument.''</Term>
<Term>&ldquo;My program entered an `absent' argument.&rdquo;</Term>
<ListItem>
<Para>
This is definitely caused by a bug in GHC. Please report it.
......@@ -289,7 +289,7 @@ This is definitely caused by a bug in GHC. Please report it.
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>``What's with this `arithmetic (or `floating') exception' ''?</Term>
<Term>&ldquo;What's with this `arithmetic (or `floating') exception' &rdquo;?</Term>
<ListItem>
<Para>
<Literal>Int</Literal>, <Literal>Float</Literal>, and <Literal>Double</Literal> arithmetic is <Emphasis>unchecked</Emphasis>.
......@@ -322,7 +322,7 @@ not-really-a problem.)
<Para>
The name of the bug-reporting game is: facts, facts, facts.
Don't omit them because ``Oh, they won't be interested&hellip;''
Don't omit them because &ldquo;Oh, they won't be interested&hellip;&rdquo;
</Para>
<Para>
......@@ -348,7 +348,7 @@ version of the operating system are you using? (<Command>uname -a</Command> or <
<Para>
Run the sequence of compiles/runs that caused the offending
behaviour, capturing all the input/output in a ``script'' (a UNIX
behaviour, capturing all the input/output in a &ldquo;script&rdquo; (a UNIX
command) or in an Emacs shell window. We'd prefer to see the whole
thing.
......
......@@ -6,7 +6,7 @@
<Para>
Installing from binary distributions is easiest, and recommended!
(Why binaries? Because GHC is a Haskell compiler written in Haskell,
so you've got to ``bootstrap'' it, somehow. We provide
so you've got to &ldquo;bootstrap&rdquo; it, somehow. We provide
machine-generated C-files-from-Haskell for this purpose, but it's
really quite a pain to use them. If you must build GHC from its
sources, using a binary-distributed GHC to do so is a sensible way to
......@@ -27,7 +27,7 @@ so binary distributions allow you to install them without having a Haskell compi
</Para>
<Para>
Binary distributions come in ``bundles,'' one bundle per file called
Binary distributions come in &ldquo;bundles,&rdquo; one bundle per file called
<Literal>&lt;bundle&gt;-&lt;platform&gt;.tar.gz</Literal>. (See the building guide for the definition of a platform.) Suppose that you untar a binary-distribution bundle, thus:
</Para>
......@@ -35,8 +35,7 @@ Binary distributions come in ``bundles,'' one bundle per file called
<Screen>
% cd /your/scratch/space
% gunzip &#60; ghc-x.xx-sun-sparc-solaris2.tar.gz | tar xvf -
</Screen>
% gunzip &#60; ghc-x.xx-sun-sparc-solaris2.tar.gz | tar xvf -</Screen>
</Para>
......@@ -209,8 +208,7 @@ moment
<Screen>
% cd /your/scratch/space
% gunzip &#60; ghc-x.xx-sun-sparc-solaris2.tar.gz | tar xvf -
% gunzip &#60; happy-x.xx-sun-sparc-sunos4.tar.gz | tar xvf -
</Screen>
% gunzip &#60; happy-x.xx-sun-sparc-sunos4.tar.gz | tar xvf -</Screen>
</Para>
......@@ -239,9 +237,6 @@ directory to <Literal>fptools</Literal> and typing <Literal>./configure</Literal
<Para>
<IndexTerm><Primary>installing in-place</Primary></IndexTerm>
<IndexTerm><Primary>in-place installation</Primary></IndexTerm>
</Para>
<Para>
You can now either start using the tools <Emphasis>in-situ</Emphasis> without going
through any installation process, just type <Literal>make in-place</Literal> to set the
tools up for this. You'll also want to add the path which <Literal>make</Literal> will
......@@ -357,7 +352,7 @@ stuff in your bin directory.
<ListItem>
<Para>
Once done, test your ``installation'' as suggested in
Once done, test your &ldquo;installation&rdquo; as suggested in
<XRef LinkEnd="sec-GHC-test">. Be sure to use a <Literal>-v</Literal>
option, so you can see exactly what pathnames it's using.
......@@ -376,7 +371,7 @@ When installing the user-invokable binaries, this installation
procedure will install GHC as <Literal>ghc-x.xx</Literal> where <Literal>x.xx</Literal> is the version
number of GHC. It will also make a link (in the binary installation
directory) from <Literal>ghc</Literal> to <Literal>ghc-x.xx</Literal>. If you install multiple versions
of GHC then the last one ``wins'', and ``<Literal>ghc</Literal>'' will invoke the last
of GHC then the last one &ldquo;wins&rdquo;, and &ldquo;<Literal>ghc</Literal>&rdquo; will invoke the last
one installed. You can change this manually if you want. But
regardless, <Literal>ghc-x.xx</Literal> should always invoke GHC version <Literal>x.xx</Literal>.
</Para>
......@@ -389,7 +384,7 @@ regardless, <Literal>ghc-x.xx</Literal> should always invoke GHC version <Litera
<Para>
<IndexTerm><Primary>bundles, binary</Primary></IndexTerm>
There are plenty of ``non-basic'' GHC bundles. The files for them are
There are plenty of &ldquo;non-basic&rdquo; GHC bundles. The files for them are
called <Literal>ghc-x.xx-&lt;bundle&gt;-&lt;platform&gt;.tar.gz</Literal>, where
the <Literal>&lt;platform&gt;</Literal> is as above, and <Literal>&lt;bundle&gt;</Literal> is one
of these:
......@@ -421,7 +416,7 @@ You'll want this if you're into that kind of thing.
<Term><Literal>gran</Literal>:</Term>
<ListItem>
<Para>
The ``GranSim'' parallel-Haskell simulator
The &ldquo;GranSim&rdquo; parallel-Haskell simulator
(hmm&hellip; mainly for implementors).
<IndexTerm><Primary>bundles, gransim</Primary></IndexTerm>
<IndexTerm><Primary>gransim bundles</Primary></IndexTerm>
......@@ -431,8 +426,8 @@ The ``GranSim'' parallel-Haskell simulator
<Term><Literal>ticky</Literal>:</Term>
<ListItem>
<Para>
``Ticky-ticky'' profiling; very detailed
information about ``what happened when I ran this program''&mdash;really
&ldquo;Ticky-ticky&rdquo; profiling; very detailed
information about &ldquo;what happened when I ran this program&rdquo;&mdash;really
for implementors.
<IndexTerm><Primary>bundles, ticky-ticky</Primary></IndexTerm>
<IndexTerm><Primary>ticky-ticky bundles</Primary></IndexTerm>
......@@ -475,8 +470,7 @@ Compile the program, using the <Literal>-v</Literal> (verbose) flag to verify th
libraries, etc., are being found properly:
<Screen>
% ghc -v -o hello Main.hs
</Screen>
% ghc -v -o hello Main.hs</Screen>
</Para>
......@@ -485,8 +479,7 @@ Now run it:
<Screen>
% ./hello
Hello, world!
</Screen>
Hello, world!</Screen>
</Para>
......@@ -499,7 +492,7 @@ distributed in <Literal>ghc/misc/examples/nfib/</Literal> in a source distributi
</Para>
<Para>
For more information on how to ``drive'' GHC, either do <Literal>ghc -help</Literal> or
For more information on how to &ldquo;drive&rdquo; GHC, either do <Literal>ghc -help</Literal> or
consult the User's Guide (distributed in several pre-compiled formats
with a binary distribution, or in source form in
<Literal>ghc/docs/users&lowbar;guide</Literal> in a source distribution).
......@@ -559,8 +552,8 @@ do the following:
</ItemizedList>
<Para>
Some environment variables are ``user variables'' and
some are ``system variables''. I'm not sure of the difference
Some environment variables are &ldquo;user variables&rdquo; and
some are &ldquo;system variables&rdquo;. I'm not sure of the difference
but both are changed though the same dialogue.
</Para>
......@@ -656,12 +649,6 @@ Create the following directories (if they aren't already there):
</Para>
</ListItem>
<ListItem>
<Para>
Add the two <Filename>bin</Filename> directories to your <Constant>PATH</Constant>.
</Para>
</ListItem>
<ListItem>
<Para>
Copy <Filename>bash.exe</Filename> from the <Filename>bin</Filename>
......@@ -677,71 +664,92 @@ directory, but (a) some UNIX utils have got
<ListItem>
<Para>
Add <Filename>C:\cygnus\cygwin-b20\H-i586-cygwin32\bin</Filename> to your <Constant>PATH</Constant>.
<Command>bash</Command> needs this, and when it is invoked from <Filename>/bin</Filename> it can't
find it.
If you're an Emacs user and want to be able to run <Command>bash</Command>
from within a shell buffer, see the <ULink URL="http://www.cs.washington.edu/homes/voelker/ntemacs.html">NT Emacs home page</ULink> for
instructions on how to set this up.
</Para>
</ListItem>
<ListItem>
</ItemizedList>
<Para>
Set your <Constant>SHELL</Constant> user environment variable to <Filename>c:/bin/sh</Filename>.