Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!cca!ima!haddock!johnl From: johnl@haddock.UUCP Newsgroups: net.unix Subject: Re: Using more than one 'yacc' in a sing - (nf) Message-ID: <56@haddock.UUCP> Date: Mon, 6-Feb-84 23:40:24 EST Article-I.D.: haddock.56 Posted: Mon Feb 6 23:40:24 1984 Date-Received: Thu, 9-Feb-84 08:34:45 EST Lines: 31 #R:sri-arpa:-1629500:haddock:16700009:000:1361 haddock!johnl Feb 6 16:53:00 1984 I also had the same problem of using yacc in more than one place in a program, but came up with a more overimplemented way of dealing with it. I wrote a program called "entry" which you would call as: $ entry aoutfile name1 name2 ... and it would fiddle bits in the aoutfile so that only the names you specified (and any undefined externals) were global. It basically retroactively declared everything else in that object file to be static. The idea was that you compiled one yacc piece, linked it with a few related modules, used "entry" on that so that only useful entries, not including yy*, were global and linked that with other stuff. You could do this recursively depending on how much symbol hiding you want to do. There were disadvantages, notably that the makefiles got ugly and the debuggers got confused in the presence of many symbols with the same name. What you really want in such a case (and what I've never seen implemented very well) is block structured link time symbol tables. At compile time if I have local variables named "i" in several routines, or even in several blocks in the same routine, it doesn't cause any trouble. It would be nice to have link time be as nice. As it is now, link time symbols are sort of like variables in early Fortran II programs -- either they're in common or they aren't. John Levine, ima!johnl