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) |
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/
Return to the
comp.compilers page.
Search the
comp.compilers archives again.