kdevelop-pg syntax/semantics

[Jakob Petsovits]

Hi Roberto et al.,

I'm sorry that I haven't had the time yet to go at it, but I'm going to start 
converting the JavaCC grammar to kdevelop-pg format Real Soon Now (TM).

For this reason, I'd like to have a short ok if I got these meanings right:
(where bla is either a terminal or a lexeme)

[bla bla]
has the kdevelop-pg syntax: (bla bla | 0)

(bla)+
is: !(bla)

(bla blo)+
is: !(bla blo) or !(#bla blo)

(bla COMMA)+ bla
can be conveniently written as: #bla @ COMMA
If I get it right, this notation is the only one able to do '(...)+' without 
writing '!(...)'. Please correct me if I'm wrong.

Values can be stored by replacing bla with
variable=bla
which puts them into struct $RULENAME_ast, and that can later be accessed with 
(*yynode)->variable.

variable:bla
produces local variables instead of struct members,
but currently the generator forgets to declare them (compile error :-).

!(#var=bla) as well as #var=bla @ COMMA
store all the 'bla's in a linked list inside struct $RULENAME_ast,
which is caused by the '#', is called a sequence, and is accessible by 
(*yynode)->var_sequence.

But I haven't yet grokked when to use !(...) and when to use !(#...),
I'd be glad if you could elaborate a little bit on that.

You can have conditions like
?[: condition :] rule
with condition being real C++ code, and rule only valid if condition == true.
Inside such a block, LA(x).kind can be used to lookahead to the xth token that 
follows, which is named Token_LEXEME in C++ if it's LEXEME in the grammar.

Single line comments start with two dashes ("--").


Do you think it would maybe be a good idea to adapt the kdevelop-pg syntax to 
a more standard one, in order to attract more developers and/or make reading 
easier? (Like "(...)+" instead of "!(...)", or having comments be C-like 
"//". Admittedly, these are the only ones that I'd replace, given my current 
state of kdevelop-pg knowledge.)


Yeah, and I even found a bug in cool.g:

> CASE expression=expression OF !(#condition=case_condition SEMICOLON)
> IN  body_expression=expression
> -> case_expression ;;

I think you were confusing case_expression with let_expression here,
judging from the original Cool grammar in the PDF you mentioned.

The correct rule would be

CASE expression=expression OF !(#condition=case_condition SEMICOLON) ESAC
-> case_expression ;;

assuming that I'm not messing up the most simple things.


Have a great time,
  Jakob