Re: STEP compiler generator

I'm not quite certain what problem you are trying to explain how to solve.
Thus, this reply has been delayed and may be off track.


> In one program it has a parser generator, interpreter for the
> generated parser, replacement procedure (what Bison calls action)
> compiler, and interpreter for compiled replacement procedures.


This sounds very much like the model used in Racket, where one
incrementally defines a new language which gets interpreted down to scheme
and executed as scheme (and Racket itself is written in scheme, in that way
if I understand correctly). This is all done by what the lisp people call
"hygenic macros" which are ways of manipulating an AST that has been
represented as S-expressions.


With a C interpreter (and there are such things) and a lexer and parser
generator written in C, one could essentially do the same thing, the same
way.


However, as our routinely wise moderator points out, the result is an
idiosyncratic language that is one of a kind and no one but the author
really understands. This is truly how to build a tower of Babel.


More importantly, if you are trying to solve the problem of writing more of
a compiler as something one can generate, you haven't actually solved any
interesting problem. Your code will still be imperative. You haven't
introduced any new model that actually makes some part of the compilation
process easier to reason about.


Compare this to the visitor pattern, which ANTLR generates. This separates
walking the parser tree (or AST) from the actions to be performed. That
may not seem like a big step, but it does remove some of the cognitive
load. It can be taken farther, but the pattern itself (documented before
ANTLR implemented it in the "Gang of Four" book on Design Patterns). And
those patterns do make various common actions easier to reason about,
because the pattern has taken and standardized it, thus encapsulating that
part of the cognitive load. This could be taken farther, but it is a good
step.


Attribute grammars are another way of reducing cognitive load, if you make
the attribute expressions separate and independent. That means in each
attribute expression you are only thinking about one issue. Only when the
attribute expressions intersect or are dependent upon each other does the
reasoning become more complex.


-------


Now, a different interpretation of what you are trying to achieve is some
kind of portability. Starting with either a lisp/scheme or C interpreter,
you would have something portable and relatively easy to convert into some
other programming language. Because you would still be interpreting it, it
would be a complete bootstrapping effort, where the output of the
compilation was a translation of the original language to a different
language.


However, the reason translations from one programming language to another
is difficult is not about the ordinary code. That part is easy. It's
about the semantic edge cases and things like I/O where the semantics are
buried in some runtime library. If two numbers added together overflow,
what happens? What happens if you index off the edge of an array? What
data types convert into each other and what is the result of the
conversion? There are myriads of questions at that level, which determine
what programs actually do and which ones are legal. That's where UNCOL
projects die.


------


And, both of those guesses about what STEP does that is unique might be
wrong......


--
******************************************************************************


Chris Clark email:
christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. Web Site: http://world.std.com/~compres
23 Bailey Rd voice: (508) 435-5016
Berlin, MA 01503 USA twitter: @intel_chris
------------------------------------------------------------------------------

Return to the comp.compilers page.
Search the comp.compilers archives again.