Related articles |
---|
WANTED: stylistic advice/guidelines for YACC and LEX timd@Starbase.NeoSoft.COM (1996-01-27) |
Re: WANTED: stylistic advice/guidelines for YACC and LEX scooter@mccabe.com (Scott Stanchfield) (1996-01-29) |
Re: WANTED: stylistic advice/guidelines for YACC and LEX rmonroe@hever.demon.co.uk (Robert F. Monroe) (1996-01-31) |
Re: WANTED: stylistic advice/guidelines for YACC and LEX rmonroe@hever.demon.co.uk (Robert F. Monroe) (1996-02-02) |
Re: WANTED: stylistic advice/guidelines for YACC and LEX Robert@hever.demon.co.uk (Robert F. Monroe) (1996-02-04) |
Re: WANTED: stylistic advice/guidelines for YACC and LEX rmonroe@hever.demon.co.uk (Robert F. Monroe) (1996-02-09) |
Re: WANTED: stylistic advice/guidelines for YACC and LEX ltribble@msmail4.hac.com (Tribble, Louis) (1996-02-09) |
From: | Robert F. Monroe <rmonroe@hever.demon.co.uk> |
Newsgroups: | comp.compilers |
Date: | 2 Feb 1996 09:51:51 -0500 |
Organization: | Compilers Central |
References: | 96-01-084 96-01-139 |
Keywords: | yacc, parse, OOP |
I wrote:
> Another thing that I have thought about for a while is using function
> pointers in the action code instead of a hardwired function call. It
> seems that you could do some really interesting things by being able
> to specify the semantic actions dynamically.
I have received some private e-mail comments on my posting and I think
that some clarification may be in order. My main thought was the idea
of being able to create a completely stripped down yacc generated
parser that basically knows nothing about the semantic actions. From
the standpoint of software engineering, that would allow the parser
for the language to be physically decoupled from the rest of the
program and stored in some form of static or dynamic link library. A
sort of 'parsing engine' that could have its semantic actions plugged
in by a program that uses it. I have played around with this idea and
it is definitely workable, but as I indicated in my post, I have not
found what I consider to be sufficient reason to justify structuring a
program in that way.
When I mentioned function pointers, that was my idea of a C language
alternative to what could be done with virtual functions in C++. That
is unquestionably not as safe as virtual functions. The C++ example
was more to the point. A class that is derived from the base yy_parse
class could override the semantic actions of the basic parser. The
basic parser would do little or nothing in terms of semantic
actions. It would really be no more than a syntax checker. So, I guess
it is more of an issue of parser reuse and tailorability than of
esoteric compiler techniques. Sorry if the statement about specifying
the semantic actions dynamically was misleading.
Bob.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.