Dear scripting users,

I'm reworking the type system in order to easily integrate with code
generators for composite types and sequences of types. I have made good
progress, existing typekits won't suffer that much (yet).

As a side effect, scripting got a bit leaner and meaner. Both the 'set' and
'do' prefixes are now optional. 'var' is still mandatory. So you can write:

var int a = 0, b = 0;
a = b = 10;

You couldn't do that in 1.x, where assignment was a 'command' (returning a
bool). In 2.x assignment is just returning the left most argument as an
expression. This means assignment can no longer fail in 2.x. In 1.x it failed
if container size (array, string,...) was not sufficient. In 2.x, the container
will expand, it's your job to check the sizes first, like in:

var array a(4), b(10); // pre-reserved sizes
 
b = foo(); // foo returns less than 10 elements
 
if ( b.size <= a.capacity)
   a = b; // real-time
else
   a = b; // not real-time, 'a' expands and may malloc.

Since assignment can no longer fail and returns the left most element, the
following code does something very unexpected:

var bool b = true;
 
b = false; // ouch ! (solution: use try b = false :( )

It will put your program in the Error state. Since the left most variable is
returned, it returns false and the program script execution detects this.
Compare with:

comp.start();
comp.start(); // ouch ! (solution: use try comp.start() :( )

Where the second line will certainly return false, and again, put the script
into the error state. This was mainly invented to detect failing commands, but
commands don't exist anymore in 2.0...

In the light of our error states discussion, I was wondering if:
1. We could remove this 'error state' behaviour when a function / expression
returns false and just ignore user code's return values.
2. and we only go into the program script's Error state if user code throws in
that script, sounds familiar, no ?

The "try foo.bar() catch {...}" script blocks that detected *one* function
returning false could be:
1. Interpreted as: "if !foo.bar() then {...}"
2. OR: be removed from the syntax altogether...

What do the script users think of all this ?

Peter