Scanner/Parser Generators Producing C++-Code - SUMMARY

Hello!


Below you find a summary of the responds I received with reference to:


Looking for scanner/parser gens producing C++ code? - SUMMARY
===============================================================


Thanks to all responding.


Guido




LIST OF RESPONDS:


There aren't any freely available. If you modified flex, which already
produces C++ compatible code, to use C++ I/O, I expect many people would be
grateful.
--
Regards,
John Levine, comp.compilers moderator
johnl@iecc.cambridge.ma.us or {spdcc|ima|world}!iecc!johnl


---------------------------------------


Date: Wed, 26 May 93 09:23:35 +0800
From: ipser@solomon.technet.sg (Ed Ipser)
Subject: C++ Translator Generator: LADE




Dear Mr. Schmidt:


Our company produces a product, LADE, which is a lexer/parser/transaltor
generator which produces C++ code. It is very much organized as a OOP
tool. If you would give me your full snail mail address, I'll send you a
complete packet of information.


Ed Ipser


---------------------------------------


Date: Fri, 28 May 93 12:44:21 +0200
From: James Kanze <kanze@us-es.sel.de>


Not really what you are looking for, but at least for the scanner, I just
use lex with a few judiciously chosen macros, and pass the output through
a shell script (mainly sed) to do some more cleaning up.


Obviously, the generated code only uses the C sub-set of C++, but in the
parts that I provide, I can (and do) use C++. And I never look at the
generated parts anyway:-).


For the parser, the problem is a bit more difficult. Ideally, the
generated parser should use a stack type, rather than just an array of
unions. In fact, because the parser typically declares the semantic value
as a union, you can't use class types directly. While I've gotten around
this by using pointers in the union, it is decidedly a hack.


And of course, the scanner still returns the semantic value to the parser
by a public variable, instead of adding it to the token in a class.


The best solution would be to get your hands on the template file that lex
and yacc use, and rewrite it. This does suppose some knowledge of the lex
and yacc internals, but much less than you'd imagine. (I've actually done
this for yacc a couple of times. On my machine, the yacc template is at
/usr/lib/yaccpar, the lex templates in the directory /usr/lib/lex.)


Anyhow, as an example of the type of macros I mean:


-------------------------------------
#undef getc
#undef putc
#define getc getcFromStream
#define putc putcToStream


inline int
getcFromStream (istream * inp)
{
        char tmp ;
        (*inp) >> tmp ;
        return (inp->eof ()) ? EOF : tmp ;
}


inline void
putcToStream (char chr , ostream* outp)
{
        (*outp) << chr ;
}


istream* yyin ;
ostream* yyout ;
---------------------------------------


The above cause yyinput to read from an istream, and yyoutput to
write to an ostream.


And the shell script I use to massage the lex output:


----------------------------------------


sed '/FILE/d
/fprintf/s/yyout/stderr/
/^yylook/s/.*/int yylook(){/
/^yyback/{
N
s/.*/int yyback( int* p , int m )/
}
/^yyinput/s/.*/int yyinput() {/
/^yyoutput/{
N
s/.*/void yyoutput( int c ) {/
}
/^yyunput/{
N
s/.*/void yyunput( int c ) {/
}
' $*
-----------------------------------------


The whole thing is anything but elegant, but it works.
--
James Kanze email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France


------------------------------------------


Date: Fri, 28 May 93 23:07:55 -0500
From: plyon@emx.cc.utexas.edu (Paul Lyon)


There was an LL(1) parser generator, called "wacco" posted to
comp.sources.misc some time ago (in Volume 19, but there were patches
posted in Volumes 20, 21, and 25). Any big archive will do here, e.g.
ftp.uu.net (I presume also ftp.uni-stuttgart.de). The generator is written
in C++ and generates C++ code, but it uses stdio.h rather than iostream.h.


There was a beta version of a scanner generator in C++ (also using stdio.h
instead of iostream.h) called "oma" done by Tim Budd and available on
cs.orst.edu. I do not know if it is still available, but one can always
look...


Now if someone would only convert Cocktail (the gmd compiler toolkit) to
C++.....


Hope this helps...


Paul Lyon


-------------------------------------------


From: davidn@csource.oz.au (david nugent)


I have done some work on Parag Patel's wacco parser, which varies somewhat
from YACC, but offers some advantages - it is based on LL(1), rather than
LR(0).


I first grabbed the parser from the InterNet because it was written in C++
(of a fashion), and I had expected it to output a parser class. Not so,
unfortunately, but I liked the simplicity of its syntax over YACC that I
stuck with it and have now modified it to output a parser class and to
both internally use and output the class which uses iostreams. Because of
the nature of the parser grammars it uses, it is also capable of
outputting a grammer which can be fed to a lexical scanner, a la GNU flex
or BSD's lex. Unfortunately, I haven't yet completed the last major stage
which is to have the lexical analyser incorporated into the class as well
- even the current release outputs the hooks by defining yylex() as a
public member.


The code as it stands represents a first pass 'port' from pseudo C++ (it
used to have some classes, but wasn't at all OOP) to AT&T 3.0. It now uses
templates, but not exceptions, in the symbol table handler. All the
C'isms have been removed and replaced with a better (imho) OOP design. It
still needs some work in its iostream interface, which is fairly rough,
but I am currently working on the lexical scanner side - I'll get back to
the other later as soon as I can bootstrap a parser/scanner generator for
itself (it is written in itself, which makes sense :)).


If you're at all interested in doing anything with this I'll be happy to
mail it your way. Otherwise, I expect to have a working scanner in a week
or two, depending on other committments. That will be the time I "release"
it for general use/comments/testing.


I am currently working on this under OS/2 2.1, with IBM's C++Set/2
compiler. It is being cross-compiled under MSDOS (BC++ & C7) and Linux
(gcc 2.2.2) also, but there is no dependance upon any OS specifics, and
requires only a working iostream library and templates.




Hope this helps,


david
--
davidn@csource.oz.au 3:632/348@fidonet 58:4100/1@intlnet 199:4242/5@rainbownet




----------------------------------


From: DAVIDN@csource.oz.au (david nugent)


Ok, here it is attached.


Since there are no real docs as to what I've done, I'll explain the
scheme.


Wacco.h contains the parser class itself, Wacco.cpp contains the class
member function definitions. What wacco now does is to produce a
sub-class of Wacco (by default: Wacco::_wacco) which contains the
functions needed by the parser. Wacco can actually output it's own
parser; toks.h and parse.cpp are the direct results. Only the lexical
scanner in scan.cpp and read.cpp are manually entered, but I hope to
replace that soon.


Apologies if there are any case mismatches in this - I hope I caught them
all, but both of the compilers (under Os/2) don't want to preserve the
filesystem case sometimes, and it goes unnoticed because OS/2 is actually
case insensitive.


The only non-portable stuff you'll find is in conf.h, where you can
define filenames used and some OS options in regards to fork(), wait()
and so on, and osfcn.h. These are both used purely by gen.cpp.


If you do anything with it, please keep in touch. Hopefully I can get
something done with the scanner shortly.


Cheers,


  david


------------------------------------------------


From: DAVIDN@csource.oz.au (david nugent)
Date: 2 Jun 93 05:39:43
X-Pmuue: WACCO.ZIP
X-Finfo: DOS,"WACCO.ZIP",,,,Binary


  [ This message contains the file 'WACCO.ZIP', which has been
      uuencoded. If you are not using Pegasus Mail, you will have to
      extract it and uudecode it manually. ]


GUIDO: I haven't included the uudecoded version of WACCO.ZIP.
GUIDO: I will mail a copy to you on request.


---------------------------------------------------




From: klamer@mi.el.utwente.nl (Klamer Schutte)


Using flex and bison will work. (The GNU lex/yacc replacements) Flex
defaults to using stdio. Using iostream should be possible -- redefine the
input fucntion (is that yyinput() ?)


Klamer
--
Klamer Schutte Tel: +31-53-892778 Fax: +31-53-340045
Dept. of Electrical Engineering -- University of Twente, The Netherlands
preferred: klamer@mi.el.utwente.nl SMTP: klamer@[130.89.33.3]


--
Guido Schmidt (stud. CS, Maths, 3rd)
schmidt@rz.uni-passau.de
University of Passau, Germany
--

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