Re: ** SPAM? (5.865) ** Re: [RFA] Java skeleton

[Joel E. Denny]

> +The parser class defines an inner class, @code{Location}, that is used
> +for location tracking.  If the parser is pure, it also defines an
> +inner interface, @code{Lexer}; address@hidden Scanner Interface} for the
> +meaning of pure parsers when the Java language is chosen.  Other than
> +these inner class/interface, and the members described address@hidden
> +Parser Interface}, all the other members and fields are preceded
> +with a @code{yy} prefix to avoid clashes with user code.

I find it hard to understand when you choose to use the yy prefix and when 
you don't.  For example, what's the difference between yyerror and error 
when the lexer interface resides in the parser class?

> +By default, the semantic stack is declared to have @code{Object} members,
> +which means that the class types you specify can be of any class.
> +To improve the type safety of the parser, you can declare the common
> +superclass of all the semantic values using the @samp{%define} directive.
> +For example, after the following declaration:
> +
> address@hidden
> +%define "union_name" "ASTNode"
> address@hidden example

Instead of "union_name", how about "value_superclass" or something else 
that's Java-oriented?

> +Contrary to C parsers, Java parsers do not use global variables; the
> +state of the parser is always local to an instance of the parser class.
> +Therefore, all Java parsers are ``pure'' in the C sense.  The
> address@hidden directive can still be used in Java, and it
> +will control whether the lexer resides in a separate class than the
> +Bison-generated parser

IMHO, this is a strange twist on the %pure-parser directive with which 
Bison users are already familiar.  To stay true to the original meaning, I 
think it would be better for the Java skeleton to ignore %pure-parser as a 
redundant declaration just as the C++ skeletons do.  Some new 
Java-specific boolean %define's would be better suited to your purposes, I 
think.

> +By default the class generated for a non-pure Java parser is abstract,
> +and the methods @code{yylex} and @code{yyerror} shall be placed in a
> +subclass (possibly defined in the additional code section).  It is
> +also possible, using the @code{%define "single_class"} declaration, to
> +define the scanner in the same class as the parser; when this
> +declaration is present, the class is not declared as abstract.
> +In order to place the declarations for the scanner inside the
> +parser class, you should use @code{%code} sections.

I'm getting lost.  Is there any way to simplify this?  What about 
something like the following:

1. Always define a YYLexer class.

2. Provide "%code lexer" to add code to YYLexer.

3. Always provide a parser class constructor that takes an object of type 
YYLexer as an argument.  (If the user wishes, he can easily write a 
convenient second constructor that just constructs a YYLexer and passes it 
to the first constructor.  Bison shouldn't provide this one automatically 
since YYLexer might not be concrete.)

4. Provide "%define parser_class_modifiers" and "%define 
lexer_class_modifiers" to specify abstract, interface, final, or other 
modifiers on these classes.  Contains just public by default?