Re: unparsing rules with kimwitu

  abate@gutturnio.students.cs.unibo.it (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
two options:
  - 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
      'intermediate-result' trees.
  - 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.


Regards,
Axel.
--
  <Axel.Belinfante@cs.utwente.nl> <URL:http://www.cs.utwente.nl/~belinfan/>
  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 comp.compilers page.
Search the comp.compilers archives again.