[antlr-interest] syntactic predicates and exceptions

[Gerrit E.G. Hobbelt]

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


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


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.

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)




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.

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.


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?




My 2 Eurocents.

Best regards,

Ger