[antlr-interest] syntactic predicates and exceptions

[Ric Klaren]

On 10/20/05, Gerrit E.G. Hobbelt <Ger.Hobbelt at bermuda-holding.com> wrote:
> From: "Ric Klaren" <ric.klaren at gmail.com>
> > With antlr3 it's just a matter of putting in different codegeneration
> > templates to tweak the code generated, so accomodating either option
> > should not be a big problem. Some extra suppor (or changes to) classes
> > in the runtime might also be required.
> >
> > For C codegen in v3 using ifs was easily implemented in the templates
> only.
>
> I'm glad to hear that as I try to follow this argument (in which I lean
> towards Nigel's opinion).

Tweaking antlr3 output is very easy. (at least to me it seems to be ;) )

> Besides that, I am probably one of those blokes not particularly interested
> in an ANTLR IDE (call me 'old fashioned') and who likes the fact that, while
> applying a wee bit of grey matter, you can easily track/debug ANTLR
> generated code.

IDE wise some nice things are happening with ANTLR. There's antlr
works by Jean Bovet that's more geared to understanding what antlr (3)
is doing. And Prashants antlr plugin which is utterly impressive (yes
I'm saying impressive, and people who know me, know that I won't say
impressive that easily..) These are the first IDE's I consider using
to be honest.

> Try yacc-tables on for size instead, ESPECIALLY when you've
> got something going on which might - the Gods forbid! - hint at a subtle bug
> in the parser generator tool itself. Or some code generator anomaly which
> didn't make into the documentation. Oh sure, stuff like that happens only to
> crazy ol' me. Yeah, right.

Well 'Hobbelt' code is a bit notorious to be honest ;)

> And then there are the times when I need something that coughs up code
> without *any* exceptions, maybe even written in such an arcane language
> like, say, 'C' for some [embedded] product.

Basically it's possible. I'm not sure wether I'll invest the time to
make the prototype C codegen work again for antlr3 a lot of stuff
changed since my last attempt at syncing with Terence. Last week we
had some nice talks on factoring the codegeneration templates for the
different generation options (AST/debug and various combinations of
such) It looks like we nailed it down and Ter is hacking away at this.
After he's done I'll get C++ up and running. Then if I got the
energy/time I'll see if I can get the C target running again.

> Bottom line: I suggest: cop out by offering both: generated code
> - with exceptions at any location where they're handy codesize-wise (Antlr
> On A Conditionals Diet(tm)), and
> - without any, for those that need 'Low On Clockticks(tm)' Health Code With
> Extra Fiber for high-performance and/or specific embedded environments (e.g.
> where exceptions are severily frowned upon as per company policy).
> Both versions do not need to be maintained by the same people, thus
> spreading the workload. And, yes, I realize this adds to the complexity of
> the antlr package as a whole. So be it.

Easy for you to decide ;P it's not your time ;) In the general case
exception don't work bad for most error handling. Consider the
overhead of checking return values after every match and building
nested if's to accomodate (or goto/longjmp's maybe) Which will slow
down the general flow of control in a parser. We also thought of using
some object that would pass down a return value 'policy' that would
either throw or return an error code. Guess we have to play a bit
around with templates and see what looks nice and above all
maintainable.

> I can't find another way to satisfy both 'groups' of developers, who have
> partly contrasting goals (ease of readability/maintainability throughout
> versus top performance of the end result: it's the application versus system
> engineers hustle all over again)

Nothing like a religious war ;) especially viewed from the sideline :)
I'd suspect
'we' would just choose the most practicall one to implement and leave
the other as an excercise to the reader..... (gotta love saying that
>:-) miss my university days teaching ;) )

As mentioned before (and also on the workshop by less objective
people) stringtemplate rocks. A lot of the codegen can be tweaked or
completely altered by just changing a few text files, no recompiling
necessary. Only if the templates don't get enough information from the
environment recompiles and tweaks to the java parts of antlr are
necessary. The only thing to be decided is how to allow users to
override templates from antlr3. Per default adding a new target
involves one java file and the necessary template file(s) So it's not
as easy to say 'just add a new target'.

> It all reminds me about the good ol' days of PCCTS, which was/is able to
> produce 'C' code without exceptions while you could write your grammar WITH
> [some sort of] exceptions - I loved that! -, so if Ric has a way to somehow
> rewrite those ANTLR exceptions to 'C' 'if' statements in the codegen
> templates, I'd be all for it to go that way, no matter how 'complex' the
> generated end result turns out to be.

Well we'll know for sure when Terence implements the backtracking
stuff for java. I suspect there will be no problems in writing things
as templates.

> Languages with exception support (java, C++, what-have-you) could then be
> offered with two templates: one 'basic', which uses native exception
> handling and puts 'clean, concise and readable' before utter parsing
> performance, and another 'high perf' one, where exceptions are rewritten as
> chunks of 'if's, etc., where looking at the code might be considered harmful
> ;-)
> You could then delegate the maintenance of the 'high perf' templates to
> those that need/want them anyway (embedded development, etc.), assuming the
> majority prefers the 'Exceptions Included' package.

Actually it depends on your parsing problem which one might be the
high performance one. All those if checks also have their performance
hit. It depends on how exceptional exceptions are... If exceptions are
rare in your grammar (and input!) then using exceptions is high
performance if they're not then the if style might be best. (Another
argument for us to implement what's easiest, can't keep all happy
anyway... we'll try but we reserve the right to be utter bastards
anyway ;) well at least for the C++ target I would anyway.. I suspect
Terence will be pragmatic with Java as well especially when seeing how
easy it is to tweak output...)

> Note that I'm not worried about 'backtracking versus other situations', but
> that I'd like to see this considered at a slightly higher level: any
> exceptions at *all*? Or exceptions at all those spots where it significantly
> reduces the LOC (Lines Of Code #) - and hence inproves the [perceived]
> legibility and maintainability?

In general I got the impression from discussions so far that we'll go
for consistency anytime. Having multiple ways of dealing with it could
be messy.

Anyway these are my impressions/opinions so far... How things are/get
actually implemented might be another ;)

Cheers,

Ric