KDevelop-PG and the resulting AST

Hi,

in the qmake_parser_experiment branch I've hit a pretty bad
problem: I
can't produce a proper AST node for this rule:

( OR #id=IDENTIFIER ( #func_args=function_args | 0 ) )
-> or_op;;

the problem is that there's no relation between the
id_sequence and the
func_args_sequence in the AST, but there is one in reality.
I tried to
put

[: (*yynode)->func_args_sequence->insert(0); :]

into the epsilon part, but that doesn't work because
kdev-pg's list
implementation is "crap" ;). 

So I'd like to get some help, either a way to introduce some
relation
between the two lists (in an ideal world kdev-pg would have
a map or
list of pair support) or wether it would make sense to drop
kdev-pg's
own list implementation and use STL for that (I'm willing to
do that)

Andreas

-- 
You will wish you hadn't.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Hi

Il giorno 21/lug/07, alle ore 19:00, Andreas Pakulat ha
scritto:

> Hi,
>
> in the qmake_parser_experiment branch I've hit a pretty
bad problem: I
> can't produce a proper AST node for this rule:
>
> ( OR #id=IDENTIFIER ( #func_args=function_args | 0 ) )
> -> or_op;;

the standard fix in LL is: introduce a new symbol. For
example, I  
have introduced a new symbol called `item'.

#item=item  OR -> or_op ;;

id=IDENTIFIER (LPAREN arg=function_args RPAREN | 0) ->
item ;;

>
> the problem is that there's no relation between the
id_sequence and  
> the
> func_args_sequence in the AST, but there is one in
reality. I tried to
> put
>
> [: (*yynode)->func_args_sequence->insert(0); :]
>
> into the epsilon part, but that doesn't work because
kdev-pg's list
> implementation is "crap" ;).

It's not crap  it's a
plain standard circular list, you don't need  
more in compiler front-ends, but it's true it needs to be
improved.

ciao robe


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 21.07.07 19:30:10, Roberto Raggi wrote:
> Il giorno 21/lug/07, alle ore 19:00, Andreas Pakulat ha
scritto:
> 
> > in the qmake_parser_experiment branch I've hit a
pretty bad problem: I
> > can't produce a proper AST node for this rule:
> >
> > ( OR #id=IDENTIFIER ( #func_args=function_args | 0
) )
> > -> or_op;;
> 
> the standard fix in LL is: introduce a new symbol. For
example, I  
> have introduced a new symbol called `item'.
> 
> #item=item  OR -> or_op ;;
> 
> id=IDENTIFIER (LPAREN arg=function_args RPAREN | 0)
-> item ;;

Damn, I shouldn't code under time-pressure  In fact I
already did
exactly that at one or two other places.

> > the problem is that there's no relation between
the id_sequence and  
> > the
> > func_args_sequence in the AST, but there is one in
reality. I tried to
> > put
> >
> > [: (*yynode)->func_args_sequence->insert(0);
:]
> >
> > into the epsilon part, but that doesn't work
because kdev-pg's list
> > implementation is "crap" ;).
> 
> It's not crap  it's a
plain standard circular list, you don't need  
> more in compiler front-ends, but it's true it needs to
be improved.

I didn't mean it literally (thus the quotes), I guess I
should've
thought about a better word. I was just surprised that it
didn't have a
way to append an entry.

Andreas

-- 
Next Friday will not be your lucky day.  As a matter of
fact, you don't
have a lucky day this year.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel