Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ima.UUCP
Path: utzoo!decvax!ima!johnl
From: johnl@ima.UUCP (Compilers mailing list)
Newsgroups: mod.compilers
Subject: Re: Incremental compilers
Message-ID: <149@ima.UUCP>
Date: Wed, 2-Jul-86 22:03:19 EDT
Article-I.D.: ima.149
Posted: Wed Jul  2 22:03:19 1986
Date-Received: Wed, 2-Jul-86 22:45:41 EDT
Reply-To: decvax!sun!hoptoad!gnu (John Gilmore)
Lines: 43
Approved: <compilers@ima.UUCP>
In-Reply-To: your article <139@ima.UUCP>

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