Sigbjorn writes:
> the following code causes Hugs (June'98) to complain
>
> module Foo where
>
> data A = A1 | .... | A101
>
> aToInt :: A -> Int
> aToInt x =
> case x of { A1 -> 1 ; .. ; An -> n ; ... A101 -> 101 }
>
> with
>
> ERROR "foo.hs": Compiled code too complex
>
> (This problem is a "Real" one - it shows up in a Haskell Office'97 library.)
The what?
You guys at Glasgow are re-implementing Office'97 in Haskell?
Shouldn't you wait until you're working at Microsoft before
you start hacking on MS products? :-)
> i.e., the compile-time constant NUM_FIXUPS is exceeded. Working around
> this isn't hard, but it'd be nice if there was no hard-wired fixup
> limit, since it requires non-local users of Foo to also have to
> recompile Hugs with a bigger setting of said constant. [ Yes, I know I
> can work around the problem on the Haskell side by splitting up a big
> case statement into smaller ones, but I'd prefer not to. ]
Tommy Thorn has already persuaded me to increase it a bit (it's
400 in my current system).
Conal Elliott has persuaded me to fix a bunch of minor problems so
I'll be cutting a new release (with this chance) RSN. Then I'll
quickly announce it on the big mailing lists before any more requests
have a chance to arrive.
> Consider this a feature request for Hugs to make use of a growable
> array abstraction internally instead of fixed sized arrays wherever
> practically useful/possible. Alternatively, provide command-line
> options to override compile-time settings.
NUM_FIXUPS is gone from the new runtime system branch - it just wasn't
necessary in the new code generator.
For other limits, the easiest fix would be to make them options of
the configure script - but there's an awful lot of them.
But, in the long term, we should remove all those hardwired limits
- there's several ways to do this... needs thought.
Alastair
ps Wouldn't it be easier to derive Enum for this particular piece of
code?
