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
|