[antlr-interest] code too large error

Jared Bunting jared.bunting at peachjean.com
Wed Dec 31 05:52:21 PST 2008


Unfortunately I can't accept any number of arguments - the language just
won't work that way as the only way to specify when the list of arguments
ends is the number of arguments.  For instance:

+ * 3 4 5

should be interpreted as essentially:

(3*4)+5

(3 & 4 are arguments to *, while "* 3 4" and 5 are arguments to +)

likewise,

* + 3 4 5
is
(3+4)*5

I don't see any way to parse this by checking the number of arguments after
the fact.

I guess I don't understand what antlr is trying to disambiguate by hoisting
those predicates into the parent rule.  In the operation rule, if the
operator is seen, then the rule to be invoked is predetermined - is there
any way to tell antlr this?

Thanks,
Jared

On Wed, Dec 31, 2008 at 2:05 AM, Thomas Brandon <tbrandonau at gmail.com>wrote:

> ANTLR combines predicates and the token lookahead when creating DFAs
> so it will still have a predictor. It will also hoist predicates from
> called rules into parent rules to disambiguate. So those rules will
> generate a fairly complex predictor.
> I would say you are better to just accept any number of arguments and
> then use action code to check for the correct number of arguments,
> either in the parser or a subsequent tree parser phase. This will
> relieve the errror, probably result in simpler, better performing code
> and simplify error handling as you can just issue a warning in your
> checking code rather than having to trap the error resulting from
> failed predicates and produce a meaningful error message.
>
> Tom.
> On Wed, Dec 31, 2008 at 5:08 PM, Jared Bunting
> <jared.bunting at peachjean.com> wrote:
> > Hello All,
> >
> > I am currently working on a parser for a language with predefined
> > specifications.  Currently, for my "operation" rule, I am getting a
> > "code too large" error from the compiler in the DFA...I am a bit
> > confused by this, and I'm not sure that I understand why the prediction
> > is so complicated - is there any way I can make this rule more
> > explicit?  From my perspective, there really should be zero prediction
> > going on other than what my gated semantic predicates do.
> >
> > Also, I would note that this is the beginning, and I am using the scoped
> > variables because eventually I will be adding essentially user defined
> > operations that can defined min and max number of arguments.
> >
> > And, for anyone not familiar, code too large occurs when a java method
> > is to large (i believe the limit is 64k).
> >
> > Any help or insight would be much appreciated.
> >
> > Thanks,
> > Jared
> >
> >
> > parser grammar MyParser;
> >
> > options {
> >  output=AST;
> >  ASTLabelType=CommonTree;
> >  tokenVocab=MyLexer;
> > }
> >
> > tokens {
> >  OPERATION_ARGS;
> > }
> >
> > @header {
> > package com.example;
> > }
> >
> > expression
> >    :    operation
> >    | literal
> >    ;
> >
> > operation
> > scope {
> >  int minArgs;
> >  int maxArgs;
> > }
> >    :    operator
> >    ( {$operation::maxArgs > 0}?=> limitedArgList
> >    | {$operation::maxArgs < 0}?=> unlimitedArgList
> >    )
> >    ;
> >
> > limitedArgList
> > scope {
> >  int argCount;
> > }
> > @init {
> >  $limitedArgList::argCount = 0;
> > }
> >    :    ( {$limitedArgList::argCount < $operation::maxArgs}?=>
> > expression { $limitedArgList::argCount++; } )*
> >    {$limitedArgList::argCount >= $operation::minArgs}? ->
> > ^(OPERATION_ARGS expression*)
> >    ;
> >
> > unlimitedArgList
> > scope {
> >  int argCount;
> > }
> > @init {
> >  $unlimitedArgList::argCount = 0;
> > }
> >    : (expression { $unlimitedArgList::argCount++; })* argListTerminator
> >    { $unlimitedArgList::argCount >= $operation::minArgs }? ->
> > ^(OPERATION_ARGS expression*)
> >    ;
> >
> > argListTerminator
> >    :
> >    {input.LA(1) == EOS}?=> ARG_LIST_TERM?
> >    | ARG_LIST_TERM
> >    ;
> >
> > operator
> >    :    operatorBinary
> >    | operatorUnary
> >    | operatorMulti
> >    ;
> >
> > operatorMulti
> > @init {
> >  $operation::minArgs = 1;
> >  $operation::maxArgs = -1;
> > }
> >    :    ALL
> >    |    ANY
> >    |    CONCATENATE
> >    ;
> >
> > operatorBinary
> > @init {
> >  $operation::minArgs = 2;
> >  $operation::maxArgs = 2;
> > }
> >    :    SUM
> >    |    SUBTRACT
> >    |    MULTIPLY
> >    |    DIVIDE
> >    |    MOD
> >    |    MAX
> >    |    MIN
> >    |    AND
> >    |    OR
> >    |    XOR
> >    |    EQUALS
> >    |    NOT_EQUALS
> >    ;
> >
> > operatorUnary
> > @init {
> >  $operation::minArgs = 1;
> >  $operation::maxArgs = 1;
> > }
> >    :    NOT
> >    | INCREMENT
> >    | DECREMENT
> >    ;
> >
> > literal
> >    :    STRING
> >    |    INTEGER
> >    |    FLOAT
> >    |    boolean
> >    ;
> >
> > boolean
> >     :    TRUE
> >     | FALSE
> >    ;
> >
> >
> >
> >
> >
> > List: http://www.antlr.org/mailman/listinfo/antlr-interest
> > Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20081231/bf00124a/attachment.html 


More information about the antlr-interest mailing list