GHC doesn't compile Happy example

[Simon Marlow]

Carlos Scheidegger writes:
> 	First, the Happy example uses some functions that exist in=20
> Hugs but not in GHC, like isAlpha, isDigit and isSpace (I think so,=20
> at least, because i type ':t isAlpha' in GHCi and get=20
> 'variable not in=20
> scope'), so I created a module called CharClasses with these=20
> functions.

This is a long-standing known bug in Hugs.  These functions are
available from the Char module.

> So, I ran happy and generated calc.hs without any problems.
>=20
> 	When I try to compile calc.hs, by doing
>=20
> 	ghc -o calc.exe calc.hs CharClasses.hs
>=20
> 	I get:
>=20
> c:/ghc/ghc-
> 5.02/libHSstd.a(PrelMain__1.o)(.text+0x16)://c/tmp/ghc1756.hc:=20
> undefined reference to `__stginit_Main'
> c:/ghc/ghc-
> 5.02/libHSstd.a(PrelMain__2.o)(.text+0x4)://c/tmp/ghc1756.hc:=20
> undefined reference to `Main_main_closure'
> c:/ghc/ghc-
> 5.02/libHSstd.a(PrelMain__2.o)(.text+0x33)://c/tmp/ghc1756.hc:=20
> undefined reference to `Main_main_closure'=20

It looks like perhaps the calc.hs module isn't declared as module Main.

> Another strange behavior is that I can only call the main function=20
> once. Any other call I get:
>=20
> Happy> main
> *** Exception: illegal operation
> Action: hGetContents
> Handle: =
{loc=3D<stdin>,type=3Dsemi-closed,binary=3DFalse,buffering=3Dline}
> Reason: handle is closed
> File: <stdin>

This is the defined behaviour of getContents: it puts the stdin Handle
in a state known as "semi-closed", wherein any further I/O operations on
it are forbidden.  Because I/O state is retained between computations,
the semi-closed state persists until the next :load or :reload command.


You can make these handles reset themselves after every evaluation by
giving GHCi the command ':set +r'.  This works because stdin, stdout and
stderr are just top-level expressions that can be reverted to their
unevaluated state in the same way as any other top-level expression
(CAF).

Cheers,
	Simon