[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Apr 15 17:28:24 1993 
Subject:Pop & Parse Trees 
From:Steve Knight 
Volume-ID:930415.03 

In a previous posting, Aaron Sloman (casually) remarked:
> Syntactically impoverished languages like lisp make it much easier to
> write programs that do textual analysis of code files!

While not disputing that Lisp is syntactically impoverished, this gives
me a good opportunity to bang a drum about the Pop compilation model.
The inability to do textual analysis of Pop programs is not due to its
syntactic richness but the lack of facilities to produce parse trees.

At the moment, there is only one variant of Pop that has a distinct
parsing phase.  In the past, this was advantageous -- because of the superior
compilation speed that arose from avoiding building expensive trees.
Slowly but surely, however, this seems like a less and less attractive 
decision.

One of the ideas behind the Pop9x demo at PLUG 92 was to show how parsing
can be retrofitted to the Pop compilation model.  There were two key ideas.

The first idea was to provide parallel procedures to the 
    pop11_comp_<blah>
family.  For example, -pop11_comp_stmnt_seq_to- would have a corresponding
-pop11_read_stmnt_seq_to- version.  These new procedures are intended to
be the ``future'' route for writing syntax words and textual analysis routines,
and so on.  (The most interesting problem is working with lconstant
syntax and macros words.)

The second idea was to provide a migration route for existing syntax words
into this scenario.  Quite simply, all the code planting routines
   sys<BLAH>
have to be intercepted and, instead of planting code directly, would
check the context first.  If the context was a pop11_comp_<blah> routine
then they would simply plant code.  If, on the other hand, it was a 
pop11_read_<blah> routine, the code would be intercepted and turned into
a parse-tree element.  This preserves the efficiency advantage of direct
code generation but opens up the ability to perform code analysis.  It
also provides a gentle migration route.

This second idea needs support to make it practical, it turns out.  In
order to reconsitute a reasonably meaningful parse-tree, it is important
to introduce ``high-level'' code-planting routines that directly 
correspond to control constructs.  e.g.

    sysWHILE, sysENDWHILE                           while endwhile
    sysIF, sysTHEN, sysELSE, sysELSEIF, sysENDIF    if then else elseif endif
    sysREPEAT, sysENDREPEAT                         repeat endrepeat
    sysCOUNT, sysENDCOUNT                           #| |#
    sysQUITLOOP( N ), sysNEXTLOOP( N )              quitloop(N), nextloop(N)

These routines have the aim of purpose of preventing generated labels and
variables from appearing at the VM level.

One of the novel aspects of this suggestion is that it provides an
interface to parse-tree building in terms of side-effecting routines
instead of functional routines.  Oddly enough, this turns out to be
quite an attractive way of building parse-trees.  In fact, it avoids 
many of the presentation problems associated with quasi-quoting in
Lisp macros.

Steve