Re: language neutral parser

[Hans Aberg]

At 14:47 +0200 2001/10/20, Axel Kittenberger wrote:
>The idea is to use XML as intermediate language, and so all the tools for it
>avaibable can be used, especially XSL.

>The actions generatet by bison could roughly look like this:
...
>would be translated by bison into something like this:
>----
><actions>
>   <action value="4">
>        <text value="printf ("\t%d\n\", "/>
>        <token value="-1" union="int32"/>
>        <text value="});"/>
>    </action>
>   <action value="5">
>        <result union="int32/">
>        <text value=" = "/>
>        <token value=0" union="int32"/>
>        <text value=";"/>
>   </action>
>
>   ...etc...
><actions/>

This <actions> stuff is probably similar to the environments I allowed one
to create.

I have some specialized stuff that makes it easy to write environments
indexed on lists (say for creating arrays) or strings (say for a list of
include files).

>Which a standard XSL processor could easily turn to in to the actual code as
>in example:
>---
>  switch (yyn) {
>case 4:
> printf ("\t%d\n", yyvsp[-1]);
>case 5:
> <int32> yyval = <int32> yyvsp[0];

My macros are specialized so that such a translation can be written by
essentially one macro acting on the whole sequence of environments. This
probably corresponds to a macro acting on a whole <actions>.

>XSL would then be the 'macro' language to generate the specific language.
>"backends". This way we would not need to invent a new language, we take one
>which is acceptable for our needs, and good implementations are already
>available.

I had some other reasons for choosing the approach, for example, I needed
to write arbitrarily nested subclasses with global definitions in C++.
Perhaps it corresponds to nested <actions>. For that, I needed to introduce
TeX style \edef's.

There were also some other reasons, like I found it convenient to define
binary strings, and then have a couple of string translation functions
available to write in different formats, such as C/C++ strings, mangled
labels, etc.

But the data that Bison generates are not very complicated.

So if somebody is interested in the XSL approach, why not write an
experimental version? One simple approach for a first version might be a
parser that can translate the stuff that Bison writes using an empty
skeleton file (containing only "%% actions") into XSL.

Also, when tweaking Bison to write its data on a suitable format for
further processing, it makes little difference which format it is on as
long as that format is easily parsable, because then one can hook up
another processor to translate it into say XSL.

In one variation of my approach, I would just let Bison generate the
environments as binary data, and then let the formatter file directly
produce the output. This could then be C/C++, XML or something. Another
variation, more similar to the XML approach, is to first generate a text
file, which the macro program can process.

  Hans Aberg