Re: target language grammars.

Zbigniew Chamski <>
14 Nov 2004 22:48:25 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: target language grammars. (Lujop) (2004-11-07)
Re: target language grammars. (2004-11-07)
Re: target language grammars. (2004-11-07)
Re: target language grammars. (Ken Rose) (2004-11-14)
Re: target language grammars. (Ira Baxter) (2004-11-14)
target language grammars. (A.T. Hofkamp) (2004-11-14)
Re: target language grammars. (Zbigniew Chamski) (2004-11-14)
| List of all articles for this month |

From: Zbigniew Chamski <>
Newsgroups: comp.compilers
Date: 14 Nov 2004 22:48:25 -0500
Organization: przy PC-cie na strychu
References: 04-11-013 04-11-018
Keywords: translator, parse
Posted-Date: 14 Nov 2004 22:48:25 EST

Larry Evans wrote:

> On 11/06/2004 02:15 PM, Ralph Boland wrote:
> [snip]
>>When translating/compiling from one language to another we normally
>>have a source language grammar but don't (to my knowledge) make much
>>use of any grammar for the target language. (Grammar here may mean
> I've never used this idea, but I've seen it in articles. The idea
> is that the source language is some type of algebra and the target
> language is also some type of algebra. The compiler transforms
> the expressions in the source language (represented as an abstract
> syntax tree, e.g. ) into the target language. I vaguely remember
> something about isomorphisms or homomorphisms or something like
> that. Maybe a search for "algebraic semantics" or "many-sorted
> algebras" along with "language translation" or something along
> those lines would produce something useful.

The very idea of compiling from grammar A into grammar B is natively
supported in Lex Augusteijn's tools Front (front-end generator) and
Doggy (a DAG optimizer generator). Both Front and Doggy are available
under GPL from Philips Research pages at

Front accepts quite a complete language specification (lexical
structure, concrete and abstract syntax, symbol table control), and
produces a parser, an unparser, and a set of access functions to
manipulate the abstract syntax trees and the symbol tables produced by
the parser.

Doggy lets you specify tree rewriting systems on abstract grammars
specidied in Front. It supports rewrite rules from grammar A into
grammar B, and within either grammar. Using the Front-generated
unparser for grammar B, the result of tree rewriting can be directly
output in the target language syntax.

I really enjoyed using these tools to implement a translator from a
custom-designed, domain-specific language into SystemC. One of the
great "discoveries" I made in that process was that the constraints on
the target grammar specifications are completely different from those on
the input grammar specs. For the input grammar, accuracy of the
front-end (parser + semantic checks) is a must: the language accepted
must match the actual input language definition, nothing more and
nothing less. For the output grammar, the key is actually the
CONVENIENCE of the abstract syntax, as long as the unparsing is correct.
    In partiuclar, there's no need to disambiguate any ambiguous parsing
cases - the intended meaning is constructed during compilation. In the
case of SystemC I did not (thanks goodness) need to support a complete
C++ grammar - I just needed the constructs occuring in the class of
programs my translator was producing.



Post a followup to this message

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