runtimeexception

_______________________________________________
SableCC-Discussion mailing list
SableCC-Discussion@...
http://lists.sablecc.org/listinfo/sablecc-discussion

Fredrik Skeel Lokke a écrit : I think you have a production like

formal_parameter_list = blablala | blablabla2;

You need to specify a name for each option :
formal_parameter_list = {firstblabla}blablala | {secondblabla}blablabla2;

So that different classes for the same production are generated :
AFormalParameterListFirstBlabla and AFormalParameterListSecondBlabla

Hope this helps,

Sebastian



_______________________________________________
SableCC-Discussion mailing list
SableCC-Discussion@...
http://lists.sablecc.org/listinfo/sablecc-discussion

Hi Frederik and Sebastian,

Sebastian's solution is correct.

This kind of unhelpful message is what happens when you modify an AST (cloning nodes, adding new nodes, etc.) before applying semantic verifications! So, do not ever do that in a compiler you write. :-)

The CST->AST functionality was developed as a M.Sc. project, and there were other concerns of much higher priority than error messages. So, I let it go through...

SableCC 4 is not written as a student project. User friendliness is one of its critical objectives. So, while, initially, I am putting rather terse yet precise error messages, I expect help, during the beta period, improving these messages to make them clearer for new users of parsing tools.

Have fun!

Etienne

I am getting the following error when trying to generate a parser:
[...]
java.lang.RuntimeException: [0,0] Redefinition of AFormalParameterList.
[...]
Does anyone have an idea of what’s going on? Any help would be appreciated..
[...]

I think you have a production like

formal_parameter_list = blablala | blablabla2;

You need to specify a name for each option :
formal_parameter_list = {firstblabla}blablala | {secondblabla}blablabla2;

So that different classes for the same production are generated : AFormalParameterListFirstBlabla and AFormalParameterListSecondBlabla
[...]

-- 
Etienne M. Gagnon, Ph.D.
SableCC:                                            http://sablecc.org
SableVM:                                            http://sablevm.org

_______________________________________________
SableCC-Discussion mailing list
SableCC-Discussion@...
http://lists.sablecc.org/listinfo/sablecc-discussion

On Tue, Apr 01, 2008 at 03:29:49PM +0200, Sebastián PEÑA SALDARRIAGA wrote:
> Fredrik Skeel Lokke a écrit :
> >
> >
> >I am getting the following error when trying to generate a parser:

[snip]

> >Verifying identifiers.
> >
> >java.lang.RuntimeException: [0,0] Redefinition of AFormalParameterList.

[snip]

It would be nice if SableCC 4 could generate suitable names for cases
that use a CST->AST transformation. I find my self writing things like
the following quite often...

       mul_exp {-> exp }
              = { a } [exp]:add_exp {-> exp.exp }
               | { b } [lhs]:mul_exp [op]:mul_op [rhs]:add_exp
               {-> New exp.binary(lhs.exp, op.op, rhs.exp }
               ;

       mul_op {-> op }
              = { a } asterix {-> New op.mul(asterix) }
               | { b } slash   {-> New op.div(slash)   }
               | { c } percent {-> New op.mod(percent) }
               ;
             
       add_exp {-> exp }
              = { a } [exp]:etc_exp {-> exp.exp }
               | { b } [lhs]:add_exp [op]:add_op [rhs]:add_exp
               {-> New exp.binary(lhs.exp, op.op, rhs.exp }
               ;
                     
       add_op {-> op }
              = { a } plus  {-> New op.add(plus)  }
               | { b } minus {-> New op.sub(minus) }
               ;
             
       etc_exp {-> exp } ....

None of those names really have a purpose, except to avoid the kind of
error message that Frederik suffered. Semicolons are used in other
generated names, and I'm pretty sure that a straightforward scheme
could be worked out, such as "production$a", "production$b", etc. If
you run out of single letters, then "production$aa", "production$ab",
etc. If CST->AST transformations are not being used the usual naming
rules would still have to apply.

BTW, I know this isn't the usual way that SableCC grammars are laid
out, but I find that lining things up vertically makes the whole thing
easier to follow. I'm sure other people have their own personal styles.

--
Jon Shapcott <eden@...>
"This is the Space Age, and we are Here To Go" - William S. Burroughs


_______________________________________________
SableCC-Discussion mailing list
SableCC-Discussion@...
http://lists.sablecc.org/listinfo/sablecc-discussion

Hi Jon,

Actually, SableCC 4 does something relatively equivalent.

First, for single alternative productions, SableCC 4 generates a single class, instead of two classes. It gets rid of the P* class. This is quite useful when working on the AST.

Second, for multiple alternative productions, SableCC 4 allows alternatives (possibly many) not to have a name, but then, these alternatives won't have a known type in the code. An example will help making things clearer:

prod1 =
  prod2 |             // unnamed
  {alt1} prod1 prod2; // named

prod2 = tok1;

Given the above grammar, SableCC 4 will generate the classes: PProd1, AAlt1Prod1, and AProd2. There won't be a class A[???]Prod1 for the unnamed alternative. (It will probably generate some class, but it won't be visible to AST users). This is different from previous SableCC behavior which allowed one alternative to be unnamed yet accessible.

This means that one won't be able to write inXXX/outXXX methods for the unnamed alternative. This is the price to pay for unnamed alternatives. Fixing the problem is easy: add a name when you want to write inXXX/outXXX methods.

Note that the alternative is present in the AST, so for example, the outAProd2() method will be called on the child of the unnamed alternative.

My hope is that this will reduce the workload of grammar writers, while not introducing unreadable methods such as inAAStatement() and inABStatement() in user code.

SableCC 4 takes this same approach (i.e. unnamed implies no direct access) to allow for parentheses in the AST grammar. In other words, the following is valid in the AST section of SableCC 4:

prod1 = (prod2 prod3)+ prod4;

But, the generated AProd1 class will only have the "PProd4 getProd4()" child getter. SableCC 4 also allows for:

prod1 = [tuples:](prod2 prod3)+ prod4;

In this case, the generated AProd1 class will contain an additional child getter: "Node getTuples()". As you see, the visible return type is Node. On a Node, you can only launch a tree walker, you can't try to get its children using a getter.

For your information, the SableCC 4 syntax is in its (probably) definitive state already at: http://sablecc.org/browser/grammars/sablecc4.sablecc3

As for grammar indentation, your approach suffers from making depth dependent on the length of the production name... Ooops, I shouldn't have opened such a can of worms. Indentation flame wars have no end... SableCC 4 might get an --indent option, if my wish comes true. ;-P

Have fun!

Etienne

It would be nice if SableCC 4 could generate suitable names for cases
that use a CST->AST transformation. I find my self writing things like
the following quite often...
[...]
None of those names really have a purpose, except to avoid the kind of
error message that Frederik suffered. [...]
[...]
BTW, I know this isn't the usual way that SableCC grammars are laid
out, but I find that lining things up vertically makes the whole thing
easier to follow. I'm sure other people have their own personal styles

-- 
Etienne M. Gagnon, Ph.D.
SableCC:                                            http://sablecc.org
SableVM:                                            http://sablevm.org

_______________________________________________
SableCC-Discussion mailing list
SableCC-Discussion@...
http://lists.sablecc.org/listinfo/sablecc-discussion