Re: STEP compiler generator

Christopher F Clark <>
Wed, 22 Jun 2022 00:20:59 +0300

          From comp.compilers

Related articles
STEP compiler generator (gah4) (2022-06-14)
Re: STEP compiler generator (gah4) (2022-06-17)
Re: STEP compiler generator (Christopher F Clark) (2022-06-22)
Re: STEP compiler generator (gah4) (2022-06-21)
Re: STEP compiler generator (gah4) (2022-06-21)
| List of all articles for this month |

From: Christopher F Clark <>
Newsgroups: comp.compilers
Date: Wed, 22 Jun 2022 00:20:59 +0300
Organization: Compilers Central
References: 22-06-045
Injection-Info:; posting-host=""; logging-data="89636"; mail-complaints-to=""
Keywords: tools
Posted-Date: 21 Jun 2022 19:24:07 EDT

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

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

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

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


Chris Clark email:
Compiler Resources, Inc. Web Site:
23 Bailey Rd voice: (508) 435-5016
Berlin, MA 01503 USA twitter: @intel_chris

Post a followup to this message

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