|
From: Andre B. <and...@gm...> - 2002-12-27 13:49:29
|
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).
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 ?
Is it better to implement some heuristic -- like:
search for '=' and look backwards for identifier and braces ...
*no-idea-if-this-works*
-- Andre
|