[antlr-interest] syntactic predicates and exceptions
Gerrit E.G. Hobbelt
Ger.Hobbelt at bermuda-holding.com
Thu Oct 20 17:02:05 PDT 2005
From: "Terence Parr" <parrt at cs.usfca.edu>
> in that error clause. :( I suppose try/finally is the answer. What
> about C++? Gotos?
Can't quote chapter and verse, but the latest ISO C/C++ standards define
try/finally (Microsoft: __try/__finally).
This would cover (GNU gcc & MSVC offer it at least) about, errr, say 90% of
the appdev market, but I hope you take into account that there are a myriad
of non-Intel embedded platforms out there, which come with C (or even C++,
good golly!) compilers which have just about noticed the old ANSI C and/or
'Stroustrup' C++ standards.
Not all of those are up to parr (pun intended) with the latest and greatest
of programming language standards, but it'd be nice if we can do without
Yucky Yacc for development there too, so I guess it's goto's for us, old
I expect you will run into all the ugly bits of code generation if you can
get antlr to generate memoryleak-free ('old') ANSI C code without any
setjmp()/signal() hack, so you might try that to test the span / capability
of new codegen concepts.
Heck, you (and Tom Moog) made it happen once with PCCTS, so why shouldn't we
try again with ANTLR v3, eh?
> Also using a return value is a drag as I have to deal with user
> return values.
May I suggest the nasty way out: creating functions with an extra
'parameter/argument' which is passed by reference, so that the called
function can set this parameter to the error-value fo choice and pass it
back to the callee? My own tweaked PCCTS copy does something like that when
generating re-entrent parsers [it's too long ago since I last looked at the
official release but I expect it's in there too]. Anyway, this 'solution'
wouldn't collide with any user return values, right?
The same parameter can be 'enhanced' to allow for passing other
'parser-global' state info up & down too.
> perhaps a separate stack for error returns? Can we get away with a
> single global instance var for errors like the old errno for old unix?
I am but a humble measly software engineer, but, puhleeeez, I beg of you:
*DON'T* EVEN CONSIDER THAT 'errno' ONE.
I suddenly recall this magnificent project where I had to create a
re-entrant, thread-safe script parser/interpreter, using yacc. Uh-huh. Yep,
the yacc became a hairy bison, and _that_ one got it's own, custom tweaked
parser skeleton, just so as to get rid of the last horrid bits of His
Globalness. It worked, but don't try this at home, Young Maintenance Paduan!
Too bad I only learned about PCCTS shortly after I got that heap of guano
working. Detailed parser error reporting to the script-programmers would
have been soooo much easier.
[Nightmare Thought: write a codegen for antlr which regurgitates the parser
as a set of SQL stored procedures. Or LISP output, anyone? That'll get your
More information about the antlr-interest