Re: WANTED: stylistic advice/guidelines for YACC and LEX

Robert F. Monroe <rmonroe@hever.demon.co.uk>
2 Feb 1996 09:51:51 -0500

          From comp.compilers

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)
| List of all articles for this month |
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.
--


Post a followup to this message

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