RE: source-to-source translators, what language for unparsers

"Quinn Tyler Jackson" <quinn_jackson2004@yahoo.ca>
Mon, 1 Jun 2009 07:20:49 -0700

          From comp.compilers

Related articles
source-to-source translators, what language for unparsers cfc@shell01.TheWorld.com (Chris F Clark) (2009-05-05)
RE: source-to-source translators, what language for unparsers quinn_jackson2004@yahoo.ca (Quinn Tyler Jackson) (2009-06-01)
| List of all articles for this month |

From: "Quinn Tyler Jackson" <quinn_jackson2004@yahoo.ca>
Newsgroups: comp.compilers
Date: Mon, 1 Jun 2009 07:20:49 -0700
Organization: Compilers Central
References: 09-05-026
Keywords: translator
Posted-Date: 01 Jun 2009 10:24:42 EDT

Chris F Clark said:


> I was recently working on the output side of Yacc++ and realized I
> want something better than what I have. In paricular, I want
> something where I can quickly take an example output (for some example
> input), add some fairly minimal markup and have it turn that into the
> appropriate sequence of output commands that recreate that output
> given that input. Repeat as needed with different sets until the
> program covers all the cases.


[...]


> 3) Meta-S supports Lua, which as I understand it, is a functional
> language defined for scripting. I don't know whether the
> substitutions get built-in, or whether one has functions tied to the
> parse tree that allow uses to save the relevant text. Attribute
> grammar systems generally remind me of this approach.


The Meta-S/Lua interface can work at two levels:


1. Rule post-match event.
2. Post-parse tree visitation.


Because the parsing approach is top down and can involve
back-tracking, whether or not approach 1 is appropriate for any given
output is a function of the input. For instance, if rule X outputs Y,
and X is invoked multiple times over the same offset due to
back-tracking, Y might be produced multiple times in the output, which
is likely not a desired effect.


Approach 2 is fairly standard in that the tree is traversed after a
parse. Which nodes on the tree get visited, and the order in which
these visits occur is entirely configurable.


Both approaches allow for the accumulation of state in Lua
variables. An example of this is the expression grammar: something
like "5+2*5" is parsed and then Lua produces the output "15" and this
can then be fetched by the host code.


Also, A-BNF (Adaptive BNF) has various directives that allow tree
construction to be manipulated in such a way that the final tree
before visitation has been adorned with attributes, nodes renamed, et
cetera, such that the final tree that gets visited has sufficient
state to allow for all kinds of things.


Finally, there are features of A-BNF and Meta-S that have not been
(read: "cannot be" since they are trade secrets) described publicly
that allow for far more than this. A long-standing project
specifically marks-up and annotates documents (in a entirely
configurable way using an external specification) and uses Meta-S as
the primary technology to achieve this. If document annotation is your
goal, I *can* put you in touch with the appropriate person with whom
to discuss these matters, however. I can be reached at
quinn@thothic.com or (604) 219-4362.


--
Quinn Tyler Jackson
Chief Scientist,
Thothic Technology Partners, LLC



Post a followup to this message

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