|[2 earlier articles]|
|Re: Command Line Interpreter email@example.com (Juergen Kahrs) (2000-07-27)|
|Re: Command Line Interpreter firstname.lastname@example.org (2000-07-27)|
|Re: Command Line Interpreter email@example.com (2000-07-29)|
|Re: Command Line Interpreter firstname.lastname@example.org (Steven D. Majewski) (2000-07-29)|
|Re: Command Line Interpreter email@example.com (2000-07-31)|
|Re: Command Line Interpreter firstname.lastname@example.org (Gregory Bond) (2000-08-04)|
|Re: Command Line Interpreter email@example.com (Chris F Clark) (2000-08-04)|
|Re: Command Line Interpreter firstname.lastname@example.org (Scott Nicol) (2000-08-04)|
|Re: Command Line Interpreter email@example.com (Frithiof Jensen) (2000-08-04)|
|Re: Command Line Interpreter firstname.lastname@example.org (Tom Moog) (2000-08-05)|
|From:||Chris F Clark <email@example.com>|
|Date:||4 Aug 2000 15:54:21 -0400|
|Organization:||The World Public Access UNIX, Brookline, MA|
|References:||00-07-055 00-07-069 00-07-093|
> This time I was just hoping that someone might have finally developed a
> tool that might be appropriate.
> To summarize what I see as problems with dealing with IOS.
> 1. Large numbers of commands.
> 2. Need to support display of associated help for keywords.
> 3. Keywords can have different meanings (and associated help strings)
> depending on where they're used.
> 4. Requirement to support multiple sessions on same parser with
> different instances in different modes (re-entrancy)
> If anyone has some tools suggestions besides flex/lex and yacc/bison,
> I'd welcome them.
While I hate to "advertise" the product Barbara Zino and I built (ca
1987-1990) and have maintained and extended since, this list of
features is a subset of the ones we originally put in Yacc++ (and part
of the problem we were trying to solve when building it).
1. It uses symbol tables for keywords allowing many keywords (and has
built in substring support that can automatically identify the
minimal substring needed, which can be overridden if a longer or
shorter substring should match).
The grammar engine itself successfully handles large grammars.
Thousands of rules are easily within its grasp.
2. It has support for displaying expected tokens or command specific
help strings. You'll have to play a little to get them to work
exactly as you want for your interactive input, but it can be done.
3. Grammars can handle context sensitive uses of keywords.
4. The object oriented output allows easy instantiation of multiple
independent parsers and each one can run a different subset or
version of the grammar (or any of them can run the same subset)
without clobbering each others internal state.
The object oriented input simplifies defining families of languages.
It's syntax is a derivative of the original yacc syntax (even the
lexer uses yacc syntax) with extensions to simplify this (and similar)
problem(s) such as EBNF (regular expression operators in the parser)
and keyword declarations.
The key drawback, its not cheap (and its not free-software, open
source, or public domain). A single user commercial license will cost
~$1k, although there are no royalties after that. Also, Yacc++ only
supports C++. If you want a C (or Java etc.) solution, it won't be of
Hope this helps,
Disclaimer: I am not an unbiased source when it comes to parser
Chris Clark Internet : firstname.lastname@example.org
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
Return to the
Search the comp.compilers archives again.