|Concrete to Abstract syntax firstname.lastname@example.org (Ron Kanagy) (1996-06-21)|
|Re: Concrete to Abstract syntax email@example.com (Brent Benson) (1996-06-23)|
|Re: Concrete to Abstract syntax firstname.lastname@example.org (1996-06-24)|
|Re: Concrete to Abstract syntax kadhim@VNET.IBM.COM ((Basim Kadhim)) (1996-06-27)|
|From:||Brent Benson <email@example.com>|
|Date:||23 Jun 1996 23:25:34 -0400|
# From: Ron Kanagy <firstname.lastname@example.org>
# Does anyone know of any good references, preferable online, that
# describes and/or gives pointers on how to convert a grammar
# representing the concrete syntax of a programming language to a
# grammar representing the abstract syntax of a language. I have a
# couple of books on language design and compiler writing, but they
# only touch upon the subject and don't describe the process in
# detail. Any help on this would be greatly appreciated.
It is very simple to come up with an abstract syntax representation of
a particular concrete syntax. There should be an abstract syntax tree
node type for every distinguishable language construct (e.g., literal
constant, identifier, if statement, assignment statement, etc.).
There should be a field in each of the node types for each distinct
piece of the language construct (e.g., the literal constant node type
would have one field that holds the literal constant itself, the
identifier node type would have one field that holds the name of the
identifier, the if statement node type might have three fields: one
for the "test part"; one for the "then part"; and one for the "else
part", and the assignment statement might have two fields: one for the
identifier whose value is being changed; and the the other for the
expression that computes the new value). For the simplest cases, you
have a field for each non-terminal in your concrete syntax grammar.
I would encourage you to make this stage of your compiler as simple
and as transparent as possible. Later passes of the compiler should
perform simplification and transformation of the tree. In my
experience, combining these two tasks leads to complex and hard to
maintain front ends.
Return to the
Search the comp.compilers archives again.