--- /dev/null
+%************************************************************************
+%* *
+<sect1>Haskell~1.4 vs.~Glasgow Haskell~3.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 programl, or you will be
+comprehensively screwed.
+
+%-------------------------------------------------------------------
+<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>
+%-------------------------------------------------------------------
+<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).
+
+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~3.00 doesn't
+handle it. Yet.
+
+</descrip>
projects / ghc-hetmet.git / blobdiff