Related articles |
---|
?? Visual YACC etc. OBRIENK@novell1.rtc-carlow.ie (KARL O'BRIEN) (1996-03-14) |
Re: ?? Visual YACC etc. jlilley@ix.netcom.com (1996-03-17) |
From: | jlilley@ix.netcom.com (John Lilley) |
Newsgroups: | comp.compilers |
Date: | 17 Mar 1996 23:20:29 -0500 |
Organization: | Netcom |
References: | 96-03-095 |
Keywords: | yacc |
OBRIENK@novell1.rtc-carlow.ie says...
>I've seen ads for Visual Parse++ in Dr. Dobbs, is it any good?
I've got Visual Parse++. It's pretty cheap ($300 or 400, I can't
remember). Tbe visual tools are good in that they help automate
conflict resolutions and are able to trace the lexing/parsing process
on the fly. I think that the visual tracing breaks down for a
language like C where the application needs to override identifier
tokens and turn them into typedefed identifiers. However, I haven't
verified that yet, nor seen how much of a real limitation it imposes.
It has some very nice features that simplify matters:
1) The ability to push lexer specification on the stack to handle
non-uniformities such as found in the C preprocessor and comments.
2) The ability to generate LALR(k) machines and resolve conflicts requiring
more than one level of lookahead.
3) Bindings for several languages. I'm using C++, and the lexer and parser
classes are conceptually very simple (you override the shift and reduce
methods in the parser to construct your trees and tables, and you have
access to the lexeme stream and production stack).
I've not pressed it into industrial use, but in my limited use I've
written a little dictionary parser that takes input from an MFC
application editing window, parses it and creates a dictionary using
tools.h++, and outputs the dictionary results. So far, so good.
John Lilley
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.