[antlr-interest] Can subrules be set to 'n-to-m'?

[Jamie Ferguson]

Thanks for the clarification, and sorry for the incorrect restatement.  

In using Antlr I very quickly discovered that the domain I'm working in
is not something Antlr was designed to handle.  I'm replacing a parser I
had written myself -- my parser handled rules in a variation of EBNF,
and it worked very well.  Antlr is a bit more restrictive, and I've had
to write extra code to handle things which it does not expect (such as
my own token stream, which allows me to mark matched tokens and reuse
the stream).  It may be that my domain is too specialized to expect
everything from a parser such as Antlr, but I also feel that the ability
to have n-m occurrences, or 0-m, etc. is pretty generic and would be
extremely useful in Antlr, even if it wasn't used often by most people.
That's just my opinion, of course.  :)

Jamie



On Fri, 2005-03-25 at 15:27 -0800, John D. Mitchell wrote:

> >>>>> "Jamie" == Jamie Ferguson <jferguson at aptas.com> writes:
> [...]
> 
> > Why do you consider these cases:
> 
> > (XYZ)*[0,n] means 0..n occurrences.  (XYZ)*[n,m] means 0, or n..m
> > occurrences.  (XYZ)*[n] means 0 or exactly n occurrences.
> 
> > not justifiable to include?
> 
> (A) Thanks for asking!
> 
> (B) To be clear, please note that I wrote that I wasn't sure whether they
> are justifiable or not.  That's a good bit different from your restatement.
> 
> (C) Basically, it's easy to argue that they aren't used much and that they
> are so close to the + variety that people would get weird behavior that
> they wouldn't understand.  It's also arguable that the zero versus some
> number of instances test should be done in a semantic pass against e.g.,
> the AST rather than in the parser.
> 
> (D) As I mentioned, I think they are actually useful; would be
> consistent and coherent with the * vs. + separation that we already have
> now; and should be in lexers, parsers, and tree walkers.
> 
> Hope this makes sense,
> 			John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20050325/f005c69f/attachment-0001.html