http://www.bitsavers.org/pdf/stanford/slac/The_STEP_Processor.pdf
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.
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.
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 77:01:28 |
Calls: | 6,716 |
Files: | 12,247 |
Messages: | 5,357,726 |