> consider this piece of code:
>
> \begin{code}
> class Dumb a where
> foo, death, something :: a
>
> instance Dumb Int where
> foo = 1
> death =
> something = 1
> \end{code}
>
> yields 'Internal Happy error' with CVS from 1999/06/30 and
> happy-1.5 (sorry,
> I didn't check out the CVS version of happy by now, so I
> cannot test that...)
I checked in a fix for Happy two days ago for this bug. The Happy in the
CVS repository is now the 1.6 release candidate, modulo one or two features
that may or may not go in.
I *strongly* reccommend that people trying to compile the latest GHC also
use the latest Happy, it's a big improvement over 1.5.
> BTW: is it just me, or does someone else notice, that every
> new version of
> ghc takes more memory to compile itself? :-)
Now, who's responsible for the profiler. Let me see, erm... Oh, it's me.
[runs and hides] :-)
> There isn't a simple way to let happy split the generated
> files into smaller
> pieces, is it? However, would that knock down memory usage?
I'm seriously thinking about having Happy generate C files for the parsing
tables with a small (GHC-specific) Haskell wrapper.
Cheers,
Simon
