|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:||Axel.Belinfante@cs.utwente.nl (Axel Belinfante)|
|Date:||20 May 2000 13:19:54 -0400|
|Organization:||Univ. of Twente, Dept. of Computer Science, Tele Informatics group|
email@example.com (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...
I have not seen the code of the site project, nor do I (think I) know
what xslt is. For a dirty (or at least: huge) example of the way
unparse rules can be (mis)used, you are, of course, welcome to have a
look at the code of kimwitu itself, in particular in the file 'gen.k'
in its distribution.
If I understand you correctly, the tree that you build during parsing
is very 'far' from a tree that would be useful to generate output
using unparse rules. Note: if all you want is to transform your tree
to another tree, then unparse rules are not the way to do it.
I do use unparse rules
- to generate output, by generating strings in the unparse rules,
and having printer functions that put those strings where I want
them in the way I want them there (e.g. in kimwitu, I use them
to generate the output files from the tree that is built from
the user's input files.)
- to walk the tree and do things for particular nodes.
For example, the 'static semantics checking' in kimwitu is
implemented using 'inline C code' in unparse rules that walk
the parse tree of kimwitu.
If you want to generate output using unparse rules, and there
is no simple correspondence between the structure of your output
and the tree that you have, then I think that you basically have
- transform your tree-built-at-parse-time to a second tree that
is closer to what you want to do during unparsing. You can do
such a transformation in several ways: structural induction
and rewrite rules come to mind (for simple examples see the
kimwitu manual). If needed, for example because the trans-
formation would be to complex to do in one step, you can even
do such a transformation in several small steps, having several
- use the full power of the unparse rules: by using multiple views
you can walk your tree in any way you want in the unparse rules.
You can even include 'inline C code' in your unparse rules.
I'm afraid that I cannot make any more practical suggestions without
getting more insight in the exact problem that your trying to solve --
feel free to give me more insight, either here or by private email.
University of Twente, Dept. of Computer Science, Formal Methods & Tools Group
P.O. Box 217; NL-7500 AE Enschede. Phone: +31 53 4893774; Fax: +31 53 4893247
Return to the
Search the comp.compilers archives again.