[antlr-interest] [C Target] User custom context handling, and parallel parsing.

[Garry Iglesias]

Hi Jim,

  I've encounter a reccurent problem using ANTLR with the C target language.
Maybe it's just that
I don't know the way to solve it but here it is:

  I need to be able to have some 'custom context' in my parser (and also in
my pure lexer filters...). This is important
because I might want to run several concurent parsings, and in my grammar I
need to be sure to have an isolated context
per thread.
  Using Java target it's simple : @lexer::members or @parser::members is ok
as it merges the target code inside the class.
  When I first used the C target I was disapointed not being able to find
how to do the same thing. I finally decide to pass my
context as a parameter of the first rule of the lexer. This works well, it's
a bit 'heavy' to write as I need to always access the
scope of my rule file, but it's works so I was quite happy with this. Note
that this works on the grammar rules (on a parser)
but this doesn't work on a lexer filter as they are not parameters to token
rules (and not even a 'root' in a filter....). I was not
really bother by this as I had no use (for now) for any context, but I will
need one for threading... :)
  The problem striked back today while I was willing to overload the
"displayRecognitionError" function. Because here too I
need the context, and in this place I have no way to be able to get my own
objects pointers. And this is not threading, and
the 'root rule parameter' trick doesn't work here.
  So maybe there are some 'hidden' clauses like @lexer::declarations and
@parser::declarations but I was unable to find any.
  Of course some of the problems could be solved by a 'Thread Local Storage'
strategy, but it would still involve some 'global'
the way I understand it and I don't want any globals ;). Moreover globals
are dangerouse even without threading when you
cascade recursve lex/par-sers using island grammar-style parsing or any
other 'uncommon' and complex usage.

  I would also add, about the concurrent parsing, that it would also benefit
from 'real streams' in input, I mean streamed input
instead of having the whole stuff 'ready'. This is not really mandatory but
it would improve greatly when a concurrent parser
component would have as input a translated output from another concurrent
parser.

  Sorry if they are already existing solutions to solve my problems, I was
just unable to find any clue in the documentation.

  Oh, I almost forget... THANKS for the Version 3.1 :)

Bests,

Garry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080818/53d89441/attachment.html