Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Linking two yacc (y.tab.o) files
Message-ID: <22714@mimsy.umd.edu>
Date: 23 Feb 90 13:51:49 GMT
References: <25E34681.3787@deimos.cis.ksu.edu> <39@mycroft.stanford.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 37

(I have deleted an unnecessary `usa' Distribution: line.)

In article <39@mycroft.stanford.edu> kon@mycroft.Stanford.EDU (Ronnie Kon)
writes:
>The correct way to do this is to run the yacc output through a sed
>script which replaces all the globals with unique names. ...

Actually, since yacc is table driven, this is really not the `best' way
to do it either, since you wind up with duplicated code.

The `best' way depends on space/time tradeoffs.  If you want the least
space possible, merge the two grammars (and, if necessary, scanners)
and see if that gives smaller tables.  Depending on the degree of
commonality, it might or might not.  If you want speed over space, or
if the merged tables are larger, change the yacc parser to take
parameters giving the tables and (if necessary) the lexing function.
You can then share the parser skeleton (/usr/lib/yaccpar, or whatever
it is called on your system) while using separate tables.

In other words, instead of calling `yyparse()', you would call
`parse(&parsedata, &lexdata)', where `parsedata' is a structure
containing (pointers to) the parser tables and a function that
implements the actions, and where lexdata is a structure containing
(pointers to) the scanner tables and the lex function itself and a
function that implements the lexer actions.  (If the lexer for both
grammars are identical, you need not bother with `lexdata'.)

This would require substantial changes to yacc (and, if you use it
similarly, lex).  Changing the names is much easier.

Note that this technique does not work with code-driven scanners such
as those produced by GLA.  If, however, you were to mix GLA and yacc,
you could still do this for the parser (and instead of &lexdata, pass
a pointer to the GLA lexing function).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris