[antlr-interest] syntactic predicates and exceptions

[Ric Klaren]

On 10/20/05, Gerrit E.G. Hobbelt <Ger.Hobbelt at bermuda-holding.com> wrote:
> 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).

Why have finally if you have destructors in C++ ?? One of those things
I really miss when dealing with Java. Basically any cleanups for a
rule you can stick into a destructor (like the C++ in 2.7.x deals with
tracing...)

> 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?

I intend to stay as clear as possible from reference counters as
possible for V3 (C++) They caused me more than enough headache for v2.
I'd rather use some allocators and do cheap
garbage collection or see if we can glue in the boehm gc. Haven't
spend much time thinking on the tree stuff yet for C++, currently
still working on getting UTF decoding to play nice with everything.
Prototype handcrafted lexers are already spitting out tokens :) with a
new basic runtime port.

> > Also using a return value is a drag as I have to deal with user
> > return values.

Well return values you can also treat as refernce parameters (well as
long as they aren't primitive in java, have to revert to sillyness
then...)

> May I suggest the nasty way out: creating functions with an extra
> 'parameter/argument' which is passed by reference, so that the called
> function 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.

Shouldn't be too much of a problem to pass along extra stuff being it
return values, scopes structures/whatever...

> > 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.

As warm fuzzy feelings about code go.. ernno isn't one of them. So
rest assured C++ codegen won't see them.

Cheers,

Ric 'who actually should be making slides in stead of writing mails...'