|unparsing rules with kimwitu email@example.com (2000-05-12)|
|Re: unparsing rules with kimwitu firstname.lastname@example.org (Martin von Loewis) (2000-05-20)|
|Re: unparsing rules with kimwitu Axel.Belinfante@cs.utwente.nl (2000-05-20)|
|From:||Martin von Loewis <email@example.com>|
|Date:||20 May 2000 13:19:11 -0400|
|Organization:||Humboldt University Berlin, Department of Computer Science|
firstname.lastname@example.org (Pietro Abate) writes:
> Now I've understood how to build parse rules (I'm able to parse a sentence
> and i.e. anlyze it with gviz), but I'm in a mess with the unparsing
> rules. I've seen the SDL rules for the site project, but they use
> a plain mapping from the common representation to html or latex.
> Instead I need to make huge transformation of the tree (I'm familiar with
> xslt...) and I've not understood if there are some other methods
> to do it or I've to build by scratch a data structure and work on it...
If you are interested in a larger kimwitu application, please have a
look at the SITE semantics analysis; it makes extensive use of
unparsing - even though no output is generated.
Unparsing is quite powerful, especially when you combine it with
function calls that perform computations. So when you want to produce
output, unparsing is the right way most of the time. Likewise, to
annotate an existing tree, unparsing is convenient. For example, to
perform name lookup in a tree, you could
- invoke one unparse view that collects all definitions in a symbol table
- invoke another unparse view that looks up all identifiers an annotates
them with an attribute pointing to the definition.
However, if you really need to perform transformations on the tree
itself before processing it further, you should have a look at
rewriting. We have not used rewriting in SITE very much, but it could
be the right tool in your case.
Return to the
Search the comp.compilers archives again.