Passing "-O" flag to ghc has solved the problem for now. But since a lot more code is yet to be written, I will keep my fingers crossed if the "-O" flag will continue to avoid the "undefined symbol" problem at the link-stage.
Looking at the intermediate code generated by ghc with "-ddump-ds" option, it seems that ghc is generating code that groups functions involved in certain call-chains (whether contributing to recursion or not), difines them in a "__letrec" block, and puts them in a tuple, and generates outer definititons of these functions by using differfent elements in the tuple. While I don't understand why this is done, it is very unreasonable to fix a limit of 62 for such tuple-sizes, because this limit can easily be exceeded by good, hand-written code, for example, when implementing parsers for complicated language definitions (not because the user-code uses big tuples, but because of the tuples generated by ghc itself). Manually analysing and restructuring the code in such cases to work around this compiler limitation is not realistic. Is this limitation purely a result of using Base-62 numbers in compiler/basicTypes/Unique.lhs ? If so, will changing this one file and redefining the mAX_TUPLE_SIZE fix the problem? The best solution perhaps is to avoid generation of such tuples altogether. I also see the following note in ghc.spec file. Is that related to the current issue ? If so, is this limitation non-existent in that particular version of GHC? ------------------- * Thu Sep 16 1999 Manuel Chakravarty - modified for GHC 4.04, patchlevel 1 (no more 62 tuple stuff); ------------------- I wish I could volunteer to fix this problem, but I don't understand what is really going on. Will somebody who knows the internals of GHC fix this? Or, is this such a low-priority task that it will never get scheduled ? Unfortunately, neither of the other two Haskell compilers are alternative solutions due to other limitations. Thanks, A.P. Rao. --- "A.P. Rao" <[EMAIL PROTECTED]> wrote: > > 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 <[EMAIL PROTECTED]> > 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 > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
