Re: [Cpptool-develop] Expression parsing

[Baptiste L. <gai...@fr...>]

----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Friday, December 27, 2002 2:47 PM
Subject: [Cpptool-develop] Expression parsing


> I started to play arround with parsing of expressions and extended the
> tokenizer.
> However I expect the expression parser gets complex, for that reason I
> want to make
> sure that all are with me so that the implementation is not useless
> afterwards.
>
> I implemented an expression parser that checks for <expresssion-list>
> which is the highest
> level expression and creates nodes for the list members.
> Additionally I implemented the next level <assignment-expression>
> partly. Which means
> only realy assignments will be recognized at the moment (conditionals
> and throws will be ignored).

What do you means by 'conditionals and throws' assignment ?

>
> Well, implementing all levels will lead to some big implementation isn't
> it.
> But I have no idea how to handle expressions in a different way, since
> we need to detect the
> hierarchy of operators to understand the expression in the right way:
>
> Just some examples to explain the reason for detailed expression parsing:
>
>    a = 10;                         this is a simple assigment to 'a' .
>    * ( a + 1 ) = 10;            whereas this is not an assignment to 'a'
> .   // we cannot simply search for assignment operator
>    fctcall( a = 10 , b = 3 )       is an assignment to 'a' and to 'b'
>       //  we need to parse until the low levels of calling fcts ?
>
> What is you feeling about this Baptiste ?

I would limit the expression parser to assignement to temporary variable for
now. This should cover 99% of the cases. Writing a good expression parser is
very complex (you need to deal with type, function call resolution, operator
overload...). We don't have all the datas to do that now, and the it does
not bring much functionnalities. My guess is that it will not be needed for
a while.

I would limit the current extension of the expression parser to detecting
assignement to unqualified identifier:

Supported: a = b = c = d in expression.
Not supported: *a = *(b+1) = c = 3;

This should be fairly simple to implement.

I propose introducing a new node type:

[locale-variable-assignement-expression]
    assigned-variable => [#unqualified-identifier]
    value => [expression]

The expression mutator would be extended to detect if a given expression is
a 'simple expression' or a 'assignement expression'. The recursion created
by the 'value' property would deal with multiple assignement.

Hopefully, this should provide us with all the datas we need for now.

> Is it better to implement some heuristic -- like:
>    search for '=' and look backwards for identifier and braces ...
> *no-idea-if-this-works*

I would extend the ExpressionMutator to detect the token '=' and check that
the expression starts with the tokens 'identifier, assign-op', and in that
case mutate to a locale-variable-assignement-expression and do the required
processing for that kind of node.

Baptiste.

>
> -- Andre