<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Hugs vs Haskell 98 and addenda</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="The Hugs 98 User's Guide"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Graphical interface for Windows"
HREF="winhugs.html"><LINK
REL="NEXT"
TITLE="Addenda to Haskell 98"
HREF="addenda.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="hugs-ug.css"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The Hugs 98 User's Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="winhugs.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="addenda.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="HASKELL98"
></A
>Chapter 5. Hugs <I
CLASS="FOREIGNPHRASE"
>vs</I
> Haskell 98 and addenda</H1
><P
>In <CODE
CLASS="OPTION"
>+98</CODE
> mode, Hugs supports
<A
HREF="http://www.haskell.org/definition/"
TARGET="_top"
>Haskell 98</A
>
and some standardized extensions
(described by addenda to the Haskell 98 report).</P
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="BUGS-HASKELL98"
>5.1. Haskell 98 non-compliance</A
></H1
><P
>Hugs deviates from Haskell 98 in a few minor ways,
listed here corresponding to the relevant sections of the Report.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="BUGS-LEXICAL"
>5.1.1. Lexical structure</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Restricted character set</DT
><DD
><P
>The Haskell report specifies that programs may be written using Unicode.
Hugs permits Unicode in strings and comments (in the appropriate locale,
see <A
HREF="locale.html"
>Section 3.3</A
>),
but identifiers are limited to the ISO8859-1 (Latin-1) subset at the moment.</P
></DD
><DT
>Limited lookahead</DT
><DD
><P
>Hugs is confused by such things as
<SPAN
CLASS="QUOTE"
>"<TT
CLASS="LITERAL"
>Just.if</TT
>"</SPAN
>,
<SPAN
CLASS="QUOTE"
>"<TT
CLASS="LITERAL"
>0xy</TT
>"</SPAN
>,
<SPAN
CLASS="QUOTE"
>"<TT
CLASS="LITERAL"
>0oy</TT
>"</SPAN
>,
<SPAN
CLASS="QUOTE"
>"<TT
CLASS="LITERAL"
>9e+y</TT
>"</SPAN
> and
<SPAN
CLASS="QUOTE"
>"<TT
CLASS="LITERAL"
>9.0e+y</TT
>"</SPAN
>,
because it doesn't look far enough ahead.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="BUGS-SYNTAX"
>5.1.2. Expressions</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Interaction of fixities with the
<TT
CLASS="LITERAL"
>let</TT
>/lambda meta-rule</DT
><DD
><P
>Hugs doesn't use the fixity of operators until after parsing, and so
fails to accept legal (but weird) Haskell 98 expressions like
<PRE
CLASS="PROGRAMLISTING"
>let x = True in x == x == True</PRE
></P
></DD
><DT
>Restricted syntax for left sections</DT
><DD
><P
>In Hugs, the expression must be an fexp
(or <TT
CLASS="LITERAL"
>case</TT
> or <TT
CLASS="LITERAL"
>do</TT
>).
Legal expressions like <TT
CLASS="LITERAL"
>(a+b+)</TT
> and
<TT
CLASS="LITERAL"
>(a*b+)</TT
> are rejected.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="BUGS-TYPES"
>5.1.3. Declarations and bindings</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Slight relaxation of polymorphic recursion</DT
><DD
><P
>Hugs's treatment of polymorphic recursion is less restrictive than Haskell 98
when the functions involved are mutually recursive.
Consider the following example:
<PRE
CLASS="PROGRAMLISTING"
>data BalancedTree a = Zero a | Succ (BalancedTree (a,a))
zig :: BalancedTree a -> a
zig (Zero a) = a
zig (Succ t) = fst (zag t)
zag (Zero a) = a
zag (Succ t) = snd (zig t)</PRE
>
As with many operations on non-regular (or nested) types,
<CODE
CLASS="FUNCTION"
>zig</CODE
> and <CODE
CLASS="FUNCTION"
>zag</CODE
>
need to be polymorphic in the element type.
In Haskell 98, the bindings of the two functions are interdependent,
and thus constitute a single binding group.
When type inference is performed on this group,
<CODE
CLASS="FUNCTION"
>zig</CODE
> may be used at different types,
because it has a user-supplied polymorphic signature.
However, <CODE
CLASS="FUNCTION"
>zag</CODE
> may not, and the example is rejected,
unless we add an explicit type signature for <CODE
CLASS="FUNCTION"
>zag</CODE
>.
(It could be argued that this is a bug in Haskell 98.)</P
><P
>In Hugs, the binding of <CODE
CLASS="FUNCTION"
>zig</CODE
> depends on that of
<CODE
CLASS="FUNCTION"
>zag</CODE
>, but not vice versa.
(The binding of <CODE
CLASS="FUNCTION"
>zag</CODE
> is considered to depend only on
the explicit signature of <CODE
CLASS="FUNCTION"
>zig</CODE
>.)
It is possible to infer a polymorphic type for <CODE
CLASS="FUNCTION"
>zag</CODE
>,
and from that for <CODE
CLASS="FUNCTION"
>zig</CODE
>.
This type matches the declared signature, so Hugs accepts this example.</P
></DD
><DT
>Relaxation of type classes</DT
><DD
><P
>Contrary to the the Report (4.3.1), Hugs allows the types of the member
functions of a class <TT
CLASS="REPLACEABLE"
><I
>C</I
></TT
> <TT
CLASS="REPLACEABLE"
><I
>a</I
></TT
>
to impose further constraints on <TT
CLASS="REPLACEABLE"
><I
>a</I
></TT
>, as in
<PRE
CLASS="PROGRAMLISTING"
>class Foo a where
op :: Num a => a -> a -> a</PRE
></P
></DD
><DT
>Different implementation of the monomorphism restriction for top-level bindings</DT
><DD
><P
>For example, Hugs rejects the following example from the
Haskell 98 Report, 4.5.5:
<PRE
CLASS="PROGRAMLISTING"
>module M where
import List
len1 = genericLength "Hello"
len2 = (2*len1) :: Rational</PRE
>
This module consists of two binding groups,
containing <CODE
CLASS="FUNCTION"
>len1</CODE
> and
<CODE
CLASS="FUNCTION"
>len2</CODE
> respectively.
Type inference on the first (<CODE
CLASS="FUNCTION"
>len1</CODE
>) triggers the
monomorphism restriction, so that <CODE
CLASS="FUNCTION"
>len1</CODE
> is assigned
the monomorphic type <TT
CLASS="LITERAL"
>(Num a => a)</TT
>.
The next step differs between Haskell 98 and Hugs:
<P
></P
><UL
><LI
><P
>In Haskell 98,
type inference is then performed on <CODE
CLASS="FUNCTION"
>len2</CODE
>,
resolving the type variable <TT
CLASS="LITERAL"
>a</TT
>
to <TT
CLASS="LITERAL"
>Rational</TT
>, and the module is legal.</P
></LI
><LI
><P
>In Hugs, the defaulting rule is applied to <CODE
CLASS="FUNCTION"
>len1</CODE
>,
instantiating the type variable <TT
CLASS="LITERAL"
>a</TT
> to
<TT
CLASS="LITERAL"
>Integer</TT
>.
Then type inference on <CODE
CLASS="FUNCTION"
>len2</CODE
> fails.</P
></LI
></UL
></P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="BUGS-MODULES"
>5.1.4. Modules</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Implicit module header</DT
><DD
><P
>In Haskell 98, if the module header is omitted, it defaults to
<SPAN
CLASS="QUOTE"
>"<TT
CLASS="LITERAL"
>module Main(main) where</TT
>"</SPAN
>.
In Hugs it defaults to <SPAN
CLASS="QUOTE"
>"<TT
CLASS="LITERAL"
>module Main where</TT
>"</SPAN
>,
because many people test small modules without module headers.</P
></DD
><DT
>Implicit export list</DT
><DD
><P
>In Haskell 98, a missing export list means all names defined in the
current module.
In Hugs, it is treated as
<SPAN
CLASS="QUOTE"
>"<TT
CLASS="LITERAL"
>(module <TT
CLASS="REPLACEABLE"
><I
>M</I
></TT
>)</TT
>"</SPAN
>,
where <TT
CLASS="REPLACEABLE"
><I
>M</I
></TT
> is the current module.
This is almost the same, differing only when an imported module is aliased as
<TT
CLASS="REPLACEABLE"
><I
>M</I
></TT
>.</P
></DD
><DT
>Type synonyms in export and import lists</DT
><DD
><P
>Hugs allows the <TT
CLASS="REPLACEABLE"
><I
>T</I
></TT
><TT
CLASS="LITERAL"
>(..)</TT
>
syntax for type synonyms in export and import lists.
It also allows the form <TT
CLASS="REPLACEABLE"
><I
>T</I
></TT
><TT
CLASS="LITERAL"
>()</TT
>
for type synonyms in import lists.</P
></DD
><DT
>Mutually recursive modules are not supported</DT
><DD
><P
>Note that although the Haskell 98 specification of the
<TT
CLASS="LITERAL"
>Prelude</TT
> and library modules is recursive,
Hugs achieves the same effect by putting most of these definitions
in a module <TT
CLASS="LITERAL"
>Hugs.Prelude</TT
> that these modules import.</P
></DD
><DT
>Weird treatment of <TT
CLASS="LITERAL"
>(:)</TT
></DT
><DD
><P
>The Hugs prelude exports <TT
CLASS="LITERAL"
>(:)</TT
> as if it were an identifier,
even though this is not permitted in user-defined modules.
This means that Hugs incorrectly rejects the following:
<PRE
CLASS="PROGRAMLISTING"
>module Foo where
import Prelude()
cs = 'a':cs</PRE
></P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="BUGS-PRIMITIVES"
>5.1.5. Predefined types and classes</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Rational literals lose precision</DT
><DD
><P
>In Haskell 98, a floating point literal like <TT
CLASS="LITERAL"
>1.234e-5</TT
>
stands for <SPAN
CLASS="QUOTE"
>"<TT
CLASS="LITERAL"
>fromRational (1234 % 100000000)</TT
>"</SPAN
>.
In particular, if the literal is of <TT
CLASS="LITERAL"
>Rational</TT
> type,
the fraction is exact.
In Hugs such literals are stored as double precision floating point numbers
before being converted to the appropriate type.
If the literal is of <TT
CLASS="LITERAL"
>Rational</TT
> type,
it usually denotes the same number, but some precision may be lost.</P
></DD
><DT
>Floating point values are printed differently</DT
><DD
><P
>Haskell 98 specifies that <CODE
CLASS="FUNCTION"
>show</CODE
> for floating point numbers
is the function <CODE
CLASS="FUNCTION"
>Numeric.showFloat</CODE
>,
but Hugs uses an internal function with slightly different semantics.</P
></DD
><DT
>Derived instances for large tuples are not supplied</DT
><DD
><P
>In Haskell 98, all tuple types are instances of
<TT
CLASS="LITERAL"
>Eq</TT
>, <TT
CLASS="LITERAL"
>Ord</TT
>, <TT
CLASS="LITERAL"
>Bounded</TT
>,
<TT
CLASS="LITERAL"
>Read</TT
>, and <TT
CLASS="LITERAL"
>Show</TT
>
if all their component types are.
Hugs defines these instances only for tuple types of size 5 or less
(3 or less in the small Hugs configuration).</P
></DD
><DT
>File locking</DT
><DD
><P
>Hugs does not attempt attempt to enforce the multiple-reader single-writer
locking on files required by Haskell 98.
Thus under Hugs programs that read and write the same file
at the same time may see an inconsistent state,
and programs that write to the same file more than once may produce
corrupt output.
Under Haskell 98, both kinds of program would fail at runtime.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="OTHER-BUGS"
>5.1.6. Other bugs in Hugs</A
></H2
><P
>Here are other known bugs in Hugs, in addition to the deviations listed
above. If you find a bug that is not listed here, please report it
either by using the bug tracking system on the
<A
HREF="http://hackage.haskell.org/trac/hugs"
TARGET="_top"
>Hugs development page</A
>
or by sending email to
<A
HREF="mailto:hugs-bugs@haskell.org"
TARGET="_top"
>hugs-bugs@haskell.org</A
>.</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Crashes on some infinite computations</DT
><DD
><P
>Normally, an infinite computation will either exhaust the Hugs heap:
<PRE
CLASS="SCREEN"
>ERROR - Garbage collection fails to reclaim sufficient space</PRE
>
overflow the Hugs stack:
<PRE
CLASS="SCREEN"
>ERROR - Control stack overflow</PRE
>
or just run indefinitely.
Occasionally, depending on the relative sizes of your heap, Hugs stack
and C stack, such expressions can overflow the C stack before exhausting
the other two.
On Unix, this usually causes a segmentation fault and causes Hugs to abort.</P
></DD
><DT
>Space leaks from top-level pattern bindings</DT
><DD
><P
>This expression runs in constant space
<PRE
CLASS="SCREEN"
>mapM_ putStrLn (repeat "y")</PRE
>
but this program does not:
<PRE
CLASS="PROGRAMLISTING"
>main = mapM_ putStrLn (repeat "y")</PRE
>
This is caused by <I
CLASS="FIRSTTERM"
>CAF-leaks</I
> —
a long-standing problem for Haskell implementations.
The problem is that <CODE
CLASS="FUNCTION"
>main</CODE
> (a Constant Applicative Form)
is being updated with an expression of the form:
<PRE
CLASS="SCREEN"
>putChar 'y' >> putChar '\n' >> mapM_ putStrLn (repeat "y")</PRE
>
and so on.
In the former case the outer <CODE
CLASS="FUNCTION"
>putChar</CODE
> expressions become
garbage after use, but now they are referenced by <CODE
CLASS="FUNCTION"
>main</CODE
>.
Some day, we hope to fix this by using a smarter garbage collector.
In the meantime, you can avoid the problem by making
the troublesome CAFs non-updatable.
For example, you could rewrite <CODE
CLASS="FUNCTION"
>main</CODE
> as the more convoluted:
<PRE
CLASS="PROGRAMLISTING"
>main = return () >>= \ _ -> mapM_ putStrLn (repeat "y")</PRE
>
Because the problematic expression is now inside a lambda that is not
reduced, its expansion will not be reachable from <CODE
CLASS="FUNCTION"
>main</CODE
>,
and will thus be garbage-collected as before.</P
></DD
></DL
></DIV
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="winhugs.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="addenda.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Graphical interface for Windows</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Addenda to Haskell 98</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
