linker errors

[A.P. Rao]

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" <aprao@yahoo.com> 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 <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
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com