Re: Command Line Interpreter

Chris F Clark <cfc@world.std.com>
4 Aug 2000 15:54:21 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: Command Line Interpreter jkahrs@castor.atlas.de (Juergen Kahrs) (2000-07-27)
Re: Command Line Interpreter bernfarr@my-deja.com (2000-07-27)
Re: Command Line Interpreter adamo@dblab.ece.ntua.gr (2000-07-29)
Re: Command Line Interpreter sdm7g@elvis.med.virginia.edu (Steven D. Majewski) (2000-07-29)
Re: Command Line Interpreter bernfarr@my-deja.com (2000-07-31)
Re: Command Line Interpreter gnb@hellcat.itga.com.au (Gregory Bond) (2000-08-04)
Re: Command Line Interpreter cfc@world.std.com (Chris F Clark) (2000-08-04)
Re: Command Line Interpreter snicol@apk.net (Scott Nicol) (2000-08-04)
Re: Command Line Interpreter faj@ericssontelebit.com (Frithiof Jensen) (2000-08-04)
Re: Command Line Interpreter tmoog@polhode.com (Tom Moog) (2000-08-05)
| List of all articles for this month |

From: Chris F Clark <cfc@world.std.com>
Newsgroups: comp.compilers
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
Keywords: parse

Bernard wrote:
> 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
any use.


Hope this helps,
-Chris


Disclaimer: I am not an unbiased source when it comes to parser
generators.


*****************************************************************************
Chris Clark Internet : compres@world.std.com
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)


Post a followup to this message

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