Field operator is evaluated in left-side of an assignment expression

[danirus]

With the code:

_
Struct ganzName { Text vorname, Text name };
Set jemand = ganzName("Udo", "Spät");
Text (jemand->vorname := "Uwe");

Tol returns an object as a result of the evaluation of "jemand->vorname", and
also changes the value of that field in variable Set "jemand".

[danirus]

This happens not only with the Field operator "->" but also with simple
variables in codes like:

_
Real a = 1;
a := 2;

When we execute that code, we get two entries for Real variable "a" in Object
Console list.

[danirus]

This bug has been resolved.
The solution is given in two files: language.cpp and btol/bgrammar/spfuninst.cpp

After the evaluation of each Tol sentence a BSyntaxObject is given as a result.
The left side of each assignment expression represents that result. When we do
something like:

_
Real a = 1;
a := 2;

The result of those first sentences is a Real variable called "a" with a value
"1". The result of the second is again a Real variable "a". The PutValue
operator, ":=", rescues that variable from wherever it was and assign it a new
value. Never creates a new variable "a", but returns a reference pointing to it.
That reference was being used as an exit result of each Tol sentence, I mean, a
sentence not embedded into another one. By other way, an embedded use of
operator ":=" returns directly to its own external scope. We can see it in the
code below:

_
Real a = 1; b = 1;

/* Using ":=" in an embedded sentence, returning a value to its own scope,

operators ? */

Set xxx = a, Real (b := 2) ?;

/* Using ":=" in a normal sentence */
Real (a := 2);

We have no notice of the first := operation because it happens inside another
sentence. But when execute the second sentece we get two "a" variables in
Console Objects list (Tolbase). That happens because := returns a reference to
"a" variable.
That could create some confusion, but the programmer could also be accustomed to
see that.

In the near time we could talk about the creation of an output log where each
tol executed sentence could be registered. That could be a first approach of
debugging sessions.