%************************************************************************
%*                                                                      *
<sect1>Haskell~1.4 vs.~Glasgow Haskell~4.00: language non-compliance
<label id="vs-Haskell-defn">
<p>
<nidx>GHC vs the Haskell 1.4 language</nidx>
<nidx>Haskell 1.4 language vs GHC</nidx>
%*                                                                      *
%************************************************************************

This section lists Glasgow Haskell infelicities in its implementation
of Haskell~1.4.  See also the ``when things go wrong'' section
(Section <ref name="What to do when something goes wrong" id="wrong">)
for information about crashes, space leaks, and other undesirable
phenomena.

The limitations here are listed in Haskell-Report order (roughly).

%************************************************************************
%*                                                                      *
<sect2>Expressions and patterns
<label id="infelicities-exprs-pats">
<p>
%*                                                                      *
%************************************************************************

<descrip>

%-------------------------------------------------------------------
<tag>Very long @String@ constants:</tag>
May not go through.  If you add a ``string gap'' every
few thousand characters, then the strings can be as long
as you like.

Bear in mind that string gaps and the @-cpp@<nidx>-cpp option</nidx>
option don't mix very well (see Section <ref id="c-pre-processor"
name="The C pre-processor">).

%-------------------------------------------------------------------
<tag>Very long literal lists:</tag>
These may tickle a ``yacc stack overflow'' error in the parser.
(It depends on the Yacc used to build your parser.)

%-------------------------------------------------------------------
<tag>Single quotes in module names:</tag>
It might work, but it's just begging for trouble.
</descrip>

%************************************************************************
%*                                                                      *
<sect2>Declarations and bindings
<label id="infelicities-decls">
<p>
%*                                                                      *
%************************************************************************

<descrip>
%-------------------------------------------------------------------
<tag>Derived instances of @Read@ and @Show@ for infix constructors:</tag>
All the carry-on about derived @readsPrec@ and @showsPrec@ for infix
constructors---we don't do it (yet).  We treat them the same way as
all other constructors.

%-------------------------------------------------------------------
<tag>Derived instances for records:</tag> Hmmm.
</descrip>

%************************************************************************
%*                                                                      *
<sect2>Module system and interface files
<label id="infelicities-Modules">
<p>
%*                                                                      *
%************************************************************************

<descrip>
%-------------------------------------------------------------------
<tag> Namespace pollution </tag>

Several modules internal to GHC are visible in the standard namespace.
All of these modules begin with @Prel@, so the rule is: don't use any
modules beginning with @Prel@ in your program, or you will be
comprehensively screwed.

% Not true anymore? -- Simon M.
%-------------------------------------------------------------------
% <tag>Can't export primitive types (e.g., @Int#@):</tag>
% Don't even try...

</descrip>

%************************************************************************
%*                                                                      *
<sect2>Numbers, basic types, and built-in classes
<label id="infelicities-numbers">
<p>
%*                                                                      *
%************************************************************************

<descrip>
% Not true anymore? We use Rationals all the way -- Simon M.
%-------------------------------------------------------------------
% <tag>Very large/small fractional constants:</tag>
% (i.e., with a decimal point somewhere) GHC does not check that these
% are out of range (e.g., for a @Float@), and bad things will inevitably
% follow.  (To be corrected?)
% 
% This problem does <em>not</em> exist for integral constants.
% 
% For very large/small fractional constants near the limits of your
% floating-point precision, things may go wrong.  (It's better than it
% used to be.)  Please report any such bugs.

%-------------------------------------------------------------------
<tag>Unchecked arithmetic:</tag>

Arguably <em>not</em> an infelicity, but... Bear in mind that
operations on @Int@, @Float@, and @Double@ numbers are
<em>unchecked</em> for overflow, underflow, and other sad occurrences.
(note, however that some architectures trap floating-point overflow
and loss-of-precision and report a floating-point
exception)<nidx>floating-point exceptions</nidx>.

Use @Integer@, @Rational@, etc., numeric types if this stuff
keeps you awake at night.

%-------------------------------------------------------------------
<tag>Multiply-defined array elements---not checked:</tag>
This code fragment <em>should</em> elicit a fatal error, but it does not:
<tscreen><verb>
main = print (array (1,1) [ 1:=2, 1:=3 ])
</verb></tscreen>
</descrip>

%************************************************************************
%*                                                                      *
<sect2>In Prelude support
<label id="infelicities-Prelude">
<p>
%*                                                                      *
%************************************************************************

<descrip>
%-------------------------------------------------------------------
<tag>Arbitrary-sized tuples:</tag>
Plain old tuples of arbitrary size <em>do</em> work.  Note that lots of
overloading can give rise to large tuples ``under the hood'' of your
program.

HOWEVER: standard instances for tuples (@Eq@, @Ord@, @Bounded@, @Ix@
@Read@, and @Show@) are available <em>only</em> up to 5-tuples.

These limitations are easily subvertible, so please ask if you get
stuck on them.

%-------------------------------------------------------------------
<tag>Unicode character set:</tag>
Haskell 1.4 embraces the Unicode character set, but GHC 4.00 doesn't
handle it. Yet.

</descrip>