[mod.compilers] Incremental compilers

johnl@ima.UUCP (Compilers mailing list) (07/01/86)

>[I have seen some papers on things like tricking yacc into restarting a parse,
>but little formal stuff on issues like symbol tables for incremental compilers.
>-John]

Getting Yacc to restart a parse is not terribly hard. I did it a few years
ago, this way (to produce a Pascal cross referencer for a pascal that had
conditional compilation):

First, run yacc on the grammar to produce the y.tab.c file. Next, some of the
variables internal to the yyparse() routine have to be made external. I
did this with an ed script via the makefile. Then, the scanner, when it sees
the (equivalent of) #ifdef, saves those particular variables on a stack.
At a #else (if there is one), it restores the variables. On seeing the #endif,
it pops the stack. This handles nested conditionals quite nicely.

(I think I described it right... it has to be over three years ago that I
did this). If there is enough mail coming in to me, I guess I'll dig up
the relevant code and post it. It was a wonderful kludge, but it worked.
(Of course, I had help from an LALR wizard to tell me which yacc variables
needed to be saved, I'm not that much of a grammar/parser jock to know.)
--
Arnold Robbins
CSNET:	arnold@emory	BITNET:	arnold@emoryu1
ARPA:	arnold%emory.csnet@csnet-relay.arpa
UUCP:	{ akgua, decvax, gatech, sb1, sb6, sunatl }!emory!arnold

"All this digital stuff is just a fad. Analog is the way to go."
	-- William M. Robbins, 1984
-- 
Send compilers mail to ima!compilers or, in a pinch to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbncca}!ima

Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

johnl@ima.UUCP (Compilers mailing list) (07/03/86)

What is the state of the art in incremental compilers?  I don't know,
but several interesting things have been done in the APL world over
the past 10 years.  HP wrote an incremental compiler for APL in
the '70s, but it was hampered by hardware that would not let you
execute things in data space, so it ended up having to interpret the
code it generated(!).  ucbvax!ibmpa!lmb (Larry Breed) can provide more info; I
don't know if he's on the list.  He was one of the chief designers of it.
Other people have designed incr. comp's for APL since then, but I don't
know if any were really built.  Larry might know.

I don't know much about what has happened since then.

John Gilmore, hoptoad!gnu

[I used HP's APL system at the time, and it was pretty neat, but I wouldn't
really call it an incremental compiler because it compiled a function at a
time, and the coupling between APL functions is pretty loose.  It did do
some interesting things -- it would compile fast, tight code that assumed that
array sizes wouldn't change, with a little defensive code at the front of the
function that trapped if that wasn't true; then it would recompile the function
with less tight code that let the sizes change but assumed that the number of
dimensions of each array wouldn't change, also with corresponding defensive
code; if that wasn't true it gave up and interpreted.  It also made a little
use of generators, i.e. if you used the expression "iota N" which returns a
vector of the numbers from 1 to N it wouldn't really generate the function
but rather a little code which would generate elements of the vector on
demand.  On the other hand, it required special microcode and didn't seem to
do much in the way of beating and dragging, which are by now well-known
techniques to avoid creating large temporary arrays when evaluating APL
expressions.

I'd be more interested in incremental compilers for languages with scoping
and other features that force you to dummy things up when doing incremental
compilation, and then to fix them up when referenced objects are finally
defined.

Chattily, John]
-- 
Send compilers mail to ima!compilers or, in a pinch to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbncca}!ima

Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

johnl@ima.UUCP (Compilers mailing list) (09/18/86)

Real-sender:


Does anyone have experience with TWS (Translator writing
System) from MetaWare?  Are the tools reliable (UL Approved?)
or are you likely to electrocute yourself or cut your fingers
off?
[Please send responses to him.  Send them to compilers if of general interest.]
-- 
Send compilers mail to ima!compilers or, in a pinch to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbncca}!ima

Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request