Re: Are there "compiler generators"?

Kaz Kylheku <>
Mon, 30 May 2022 20:20:44 -0000 (UTC)

          From comp.compilers

Related articles
[4 earlier articles]
Re: Are there "compiler generators"? (Thomas Koenig) (2022-05-29)
Re: Are there "compiler generators"? (Martin Ward) (2022-05-29)
Re: Are there "compiler generators"? (Fernando) (2022-05-29)
Re: Are there "compiler generators"? (gah4) (2022-05-29)
Re: Are there "compiler generators"? (2022-05-30)
Re: Are there "compiler generators"? (Hans-Peter Diettrich) (2022-05-30)
Re: Are there "compiler generators"? (Kaz Kylheku) (2022-05-30)
Re: Are there "compiler generators"? (Hans-Peter Diettrich) (2022-05-31)
Re: Are there "compiler generators"? (gah4) (2022-05-31)
Re: Are there "compiler generators"? (Roger L Costello) (2022-06-01)
Re: Are there "compiler generators"? (2022-06-01)
Re: Are there "compiler generators"? (gah4) (2022-06-01)
Re: Are there "compiler generators"? ( (2022-06-07)
[2 later articles]
| List of all articles for this month |

From: Kaz Kylheku <>
Newsgroups: comp.compilers
Date: Mon, 30 May 2022 20:20:44 -0000 (UTC)
Organization: A noiseless patient Spider
References: 22-05-054
Injection-Info:; posting-host=""; logging-data="94264"; mail-complaints-to=""
Keywords: code, design
Posted-Date: 30 May 2022 16:27:52 EDT

On 2022-05-28, Roger L Costello <> wrote:
> Hi Folks,
> There are lexer generators. Flex is a lexer generator.
> There are parser generators. Bison is a parser generator.
> Are there compiler generators?

Writing a compiler isn't something that, as a whole, requires code

The reason is that the bulk of it can be handled by libraries.

Say you want to write a working compiler with minimal effort.

You have some input syntax and so for that there is scanner and parser
generation with which you write your front end.

What helps you avoid writing the middle, and the back-end from scratch?
More code generation of some kind?

Quite simply, some compiler construction components which have API's
that you use. Ideally speaking, here is something like how it goes: in
your parser's actions, you use the API's to generate the right
intermediate representation of the code, and then hand it off to some
function that handles the remaining processing. The resulting compiler
then fits into an existing toolchain framework as a first-class

There isn't any part of that process which screams "this needs code
generation". Really, doing the pattern matching to handle your source
syntax and translate it into the intermediate representation is the main
part of the system that benefits from code generation, and
that's about it.

What could help you would be a specialized parser construction language
which has some constructs that can be used in the actions to ease the
translations to the intermediate form. That would then be closer to a
"compiler generator", perhaps: something that not only writes the
parser, where you write procedural code for every phrase structure rule,
but something which has a rewrite notation that lets write the
source->intermediate translation scheme declaratively, using higher
level concepts from that particular intermediate rep, rather than, say,
low C language calls into its API.

TXR Programming Language:
Cygnal: Cygwin Native Application Library:

Post a followup to this message

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