RE: Separation of parsing from AST construction and attribute evaluation

Quinn Tyler Jackson <quinn-j@shaw.ca>
2 Oct 2004 16:16:53 -0400

          From comp.compilers

Related articles
Separation of parsing from AST construction and attribute evaluation ralphpboland@yahoo.com (2004-10-02)
RE: Separation of parsing from AST construction and attribute evaluati quinn-j@shaw.ca (Quinn Tyler Jackson) (2004-10-02)
RE: Separation of parsing from AST construction and attribute evaluati quinn-j@shaw.ca (Quinn Tyler Jackson) (2004-10-09)
| List of all articles for this month |

From: Quinn Tyler Jackson <quinn-j@shaw.ca>
Newsgroups: comp.compilers
Date: 2 Oct 2004 16:16:53 -0400
Organization: Compilers Central
References: 04-10-006
Keywords: parse
Posted-Date: 02 Oct 2004 16:16:53 EDT

Ralph Boland said:


> I am designing a parser generator tool and I want it to work such that
> the specification for parsing an input language is entirely
> implementation language independant. Thus the same specification may
> be used to construct a parser in several different implementation
> languages.


Well, it's not "exactly" what you want, but I merged interpreted Lua into
Adaptive-BNF in such a way that it became possible to write "portable"
grammars whose reduction code runs across all platforms that compile the
core parsing library. For instance:


grammar Foo
{
S ::= a b c;
a ::= '[a-z]+';
b ::= '[0-9]+';
c ::= '[A-Z]+';


@function_impls = :{
function a_event(P)
if(P:MATCHED())
print("EVENT: " .. P:LEXEME());
end
end


function c_event(P)
-- etc
end


function b_visit(N, H) -- n = node being visited, H is handle to parsed
input
print("VISIT: " .. N:GetLexeme(H));
end
}:;
};


Given the input:


abc123ABC


the above grammar will "output" --


EVENT: abc
VISIT: ABC


An example of this is an expression evaluator that, immediately after
parsing input in the form of long expressions, outputs their standard
solution (ie. 1+5*10 displays "51").


What's more, since the Lua events and visits occur in interpreted code, the
reduction and event code (and their support functions) can be single stepped
and debugged within the same visual parsing tool that the grammar itself
can. As you single step through your productions, if those productions
invoke reduction code, you can also single step through the associated Lua
code, view the Lua variables, the Lua stack, et al.


But let me show some screen shots:


http://members.shaw.ca/qjackson/cs/metas/screens.html


If you click on the "thumbnails" -- the Lua debugger one in particular,
you'll get a better idea of what I mean.


What this means is that it is entirely possible to write a parser that does
some ad hockery during a parse but does so in a Language Independent way --
except really -- not quite what you want, since it does so in Lua -- not
"really" language independent.


The same grammar can be loaded into a C++ host, a C# host, a VB.NET host, or
even a Word document that has event handlers that instantiate the Meta-S
parsing engine as a COM automation object. The reduction code is ABSOLUTELY
the same in all hosts -- no rewriting of either the grammar or the reduction
code required to effect a proper parse.


In order to accommodate different "output" models, output doesn't really
"print" -- it calls back a host specific callback that does the actual
output.


--
Quinn Tyler Jackson
http://members.shaw.ca/qjackson/


Post a followup to this message

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