The code is hand-written and the maximum tuple-size used is 4. It works fine in Hugs. It uses the Parsec library (not the version in GHC's "text" package, but from a local copy. The ParsecPrim.hs was replaced by the version from Parsec's web-site -- it works as I expected, but not the one distributed with GHC or Hugs). The code makes straight-forward use of Parsec combinators for parsing ASN.1, and I can't see a nesting of anything close to 62 mutually recursive functions. If there is a "readme" type of document that explains the names and the tables generated in the ".hc" files, it may help me track down what construct is causing this problem. Right now, I can't recognize anything in the lines surrounding the place where this DataziTuple_Z73T_con_info symbol is used in the ".hc" file. Thanks, A.P. Rao. --- Simon Peyton-Jones <simonpj@microsoft.com> wrote:
One of GHC's infelicities is that it only supports tuples up to a certain size -- currently 62. You just can't get bigger tuples. Your program uses a 73-tuple. My guess is that your code is generated by some other program that's generating big tuples?
The only workaround is to nest your tuples.
It would really be much better if GHC complained in the front end about over-size tuples. I'll fix that. The "real" fix (arbitrary size tuples) isn't really hard, but it involves real work so we keep postponing it on the gounds that it seldom bites. So please continue to say if it bites you, so that we know.
It used to be the case that simply having a nest of more than 62 mutually-recursive functions would trigger this bug, but that should no longer be the case with 6.0. Please say if that is happening.
Simon
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com