%************************************************************************
%*                                                                      *
\section[vs-Haskell-defn]{Haskell~1.3 vs.~Glasgow Haskell~2.01: language non-compliance}
\index{GHC vs the Haskell 1.3 language}
\index{Haskell 1.3 language vs GHC}
%*                                                                      *
%************************************************************************

This section lists Glasgow Haskell infelicities in its implementation
of Haskell~1.3.  See also the ``when things go wrong'' section
(\sectionref{wrong}) for information about crashes, space leaks, and
other undesirable phenomena.

GHC~2.01 does not have a ``Haskell~1.2 compatibility mode.''  If
enough people yelled loudly and long enough, it could conceivably
happen...

The limitations here are listed in Haskell-Report order (roughly).
%Limitations related to Glasgow extensions (unboxed numbers, etc.) are
%given thereafter (\sectionref{infelicities-Glasgow-exts}).

%************************************************************************
%*                                                                      *
\subsection[infelicities-exprs-pats]{Expressions and patterns}
%*                                                                      *
%************************************************************************

\begin{description}
%-------------------------------------------------------------------
\item[No @n+k@ patterns:]
We took them out of GHC, because we thought they weren't going to
survive into Haskell~1.3.  But they did.  And we haven't put them
back.  Yet.

%-------------------------------------------------------------------
\item[Very long @String@ constants:]
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 \tr{-cpp}\index{-cpp option}
option don't mix.  The C-preprocessor may munch the backslashes.

%-------------------------------------------------------------------
\item[Very long literal lists:]
These may tickle a ``yacc stack overflow'' error in the parser.
(It depends on the Yacc used to build your parser.)

%-------------------------------------------------------------------
\item[Single quotes in module names:]
It might work, but it's just begging for trouble.
\end{description}

%************************************************************************
%*                                                                      *
\subsection[infelicities-decls]{Declarations and bindings}
%*                                                                      *
%************************************************************************

\begin{description}
%-------------------------------------------------------------------
\item[Derived instances of @Read@ and @Show@ for infix constructors:]
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.

%-------------------------------------------------------------------
\item[Derived instances for records:] Hmmm.
\end{description}

%************************************************************************
%*                                                                      *
\subsection[infelicities-Modules]{Module system and interface files}
%*                                                                      *
%************************************************************************

\begin{description}
%-------------------------------------------------------------------
\item[Can't export primitives types (e.g., \tr{Int#}):]

Don't even try...
\end{description}

%************************************************************************
%*                                                                      *
\subsection[infelicities-numbers]{Numbers, basic types, and built-in classes}
%*                                                                      *
%************************************************************************

\begin{description}
%-------------------------------------------------------------------
\item[Very large/small fractional constants:]
(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} 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.

%-------------------------------------------------------------------
\item[Unchecked arithmetic:]
Arguably {\em not} an infelicity, but... Bear in mind that operations
on \tr{Int}, \tr{Float}, and \tr{Double} numbers are {\em unchecked}
for overflow, underflow, and other sad occurrences.

Use \tr{Integer}, \tr{Rational}, etc., numeric types if this stuff
keeps you awake at night.

%-------------------------------------------------------------------
\item[Multiply-defined array elements---not checked:]
This code fragment {\em should} elicit a fatal error, but it does not:
\begin{verbatim}
main = print (array (1,1) [ 1:=2, 1:=3 ])
\end{verbatim}
\end{description}

%************************************************************************
%*                                                                      *
\subsection[infelicities-Prelude]{In Prelude support}
%*                                                                      *
%************************************************************************

\begin{description}
%-------------------------------------------------------------------
\item[Polymorphic @seq@:]
Required by the Haskell~1.3 prelude; not done yet.  Consequently,
the @strict@ function doesn't really do what you want either.

%-------------------------------------------------------------------
\item[Arbitrary-sized tuples:]
Plain old tuples of arbitrary size {\em do} 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} up to 5-tuples.

These limitations are easily subvertible, so please ask if you get
stuck on them.
\end{description}