kdevelop-pg syntax/semantics

[Roberto Raggi]

Hi Jakob!

On Wednesday 19 October 2005 23:34, you wrote:
> 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).
Sorry, but I was in San Francisco the last week. I didn't have time to check 
my email.

>
> 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)
yeap. the operator 0 can be use to make "optional" an item (e.g. (blah | 0) 
or to kill an item (0 | blah).

>
> (bla)+
> is: !(bla)
not really :-)  the bang operator means an optional sequence of "blah" so it's 
more like bla* than bla+.. kdevelop-pg doesn't have a + operator (but 
actually it is a good idea and i'm going to add it). If you want blah+ you 
need to write (blah !blah)

>
> (bla blo)+
> is: !(bla blo) or !(#bla blo)
hmm.. the # annotation is something different. The idea is to automagically 
create the AST from the grammar specification. To create the AST you need to 
annotate the items. An annotation looks like an assignment. There are two 
different way to annotate an item.
  1) a=an_item
  2) #a=an_item

you need to use (1) to store a single item in the AST - (2) if 
you want to store a sequence of items. For instance

   op=MINUS e=primary_expression
 | e=primary_expression
-> unary_expression ;;

kdev-pg generates an AST with two elements "op" of type token and "e" of type 
unary_expression_ast

     !#decl=declaration
-> declaration_sequence ;;

in this case the generated AST node for declaration_sequence contains a 
"sequence" of item "declaration". The attribute has type List!

>
> (bla COMMA)+ bla
> can be conveniently written as: #bla @ COMMA
hmmm the @ operator is pretty useful for LL grammars!
item @ token is translated to 
item !(token item)

# is very useful for things like "expressions". For example,

mult_expr !((PLUS|MINUS) mult_expr)
-> add_expr ;;

can be written as
mult_expr @ (PLUS | MINUS)
-> add_expr ;;


> If I get it right, this notation is the only one able to do '(...)+'
> without writing '!(...)'. Please correct me if I'm wrong.
I'm not sure i get it.. 

>
> 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.
yep!

>
> variable:bla
> produces local variables instead of struct members,
> but currently the generator forgets to declare them (compile error :-).
you have to declare the variable.. you add C++ code inside the bracket-dot 
operator [: c++ code here!   :]

>
> !(#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.
yeap!

>
> 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 need the # annotation only if you want to create store the item in the 
AST.

>
> 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.
yeap

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

>
>
> 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.)
I think I can add it

>
> Yeah, and I even found a bug in cool.g:
> > CASE expression=expression OF !(#condition=case_condition SEMICOLON)
> > IN  body_expression=expression
> > -> case_expression ;;
cool :-)

>
> I think you were confusing case_expression with let_expression here,
> judging from the original Cool grammar in the PDF you mentioned.
The grammar has a couple of problem :-) I'll submit a new version later today

ciao robe