</Para>
<Sect1 id="wrong-compiler">
-<Title>When the compiler ``does the wrong thing''
+<Title>When the compiler “does the wrong thing”
</Title>
<Para>
<VariableList>
<VarListEntry>
-<Term>``Help! The compiler crashed (or `panic'd)!''</Term>
+<Term>“Help! The compiler crashed (or `panic'd)!”</Term>
<ListItem>
<Para>
These events are <Emphasis>always</Emphasis> bugs in the GHC system—please report them.
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>``The compiler ran out of heap (or stack) when compiling itself!''</Term>
+<Term>“The compiler ran out of heap (or stack) when compiling itself!”</Term>
<ListItem>
<Para>
It happens. We try to supply reasonable <Option>-H<n></Option> flags for
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>``The compiler died with a pattern-matching error.''</Term>
+<Term>“The compiler died with a pattern-matching error.”</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 “panic.” Please report it.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>``This is a terrible error message.''</Term>
+<Term>“This is a terrible error message.”</Term>
<ListItem>
<Para>
If you think that GHC could have produced a better error message,
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>``What about these `trace' messages from GHC?''</Term>
+<Term>“What about these `trace' messages from GHC?”</Term>
<ListItem>
<Para>
Almost surely not a problem. About some specific cases…
</Para>
<Para>
-If the simplifier definitely seems to be ``looping,'' please report
+If the simplifier definitely seems to be “looping,” please report
it.
</Para>
</ListItem>
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>``What about this warning from the C compiler?''</Term>
+<Term>“What about this warning from the C compiler?”</Term>
<ListItem>
<Para>
-For example: ``…warning: `Foo' declared `static' but never defined.''
+For example: “…warning: `Foo' declared `static' but never defined.”
Unsightly, but shouldn't be a problem.
</Para>
</ListItem>
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>``I think GHC is producing incorrect code'':</Term>
+<Term>“I think GHC is producing incorrect code”:</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 “lint”
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% in compile time.
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>``Why did I get a link error?''</Term>
+<Term>“Why did I get a link error?”</Term>
<ListItem>
<Para>
If the linker complains about not finding <Literal>_<something>_fast</Literal>, then
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>``What's a `consistency error'?''</Term>
+<Term>“What's a `consistency error'?”</Term>
<ListItem>
<Para>
(These are reported just after linking your program.)
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>``Is this line number right?''</Term>
+<Term>“Is this line number right?”</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 “allow” 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>
</Sect1>
<Sect1 id="wrong-compilee">
-<Title>When your program ``does the wrong thing''
+<Title>When your program “does the wrong thing”
</Title>
<Para>
<VariableList>
<VarListEntry>
-<Term>``Help! My program crashed!''</Term>
+<Term>“Help! My program crashed!”</Term>
<ListItem>
<Para>
(e.g., a `segmentation fault' or `core dumped')
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 “arity” of a value), then duff code may result.
Furthermore, arities may change even if types do not.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
-<Term>``My program entered an `absent' argument.''</Term>
+<Term>“My program entered an `absent' argument.”</Term>
<ListItem>
<Para>
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>“What's with this `arithmetic (or `floating') exception' ”?</Term>
<ListItem>
<Para>
<Literal>Int</Literal>, <Literal>Float</Literal>, and <Literal>Double</Literal> arithmetic is <Emphasis>unchecked</Emphasis>.
<Para>
The name of the bug-reporting game is: facts, facts, facts.
-Don't omit them because ``Oh, they won't be interested…''
+Don't omit them because “Oh, they won't be interested…”
</Para>
<Para>
<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 “script” (a UNIX
command) or in an Emacs shell window. We'd prefer to see the whole
thing.