CoCoA » CoCoA-5

In Interpreter.C around line 2065 there is:

bool IndexedAccess::assignmentNeedsOwnership() const {
    return true;
}

In Interpreter.C around line 4210 there is:

void AssignmentStatement::implExecute(RuntimeEnvironment *runtimeEnv) {
    const intrusive_ptr<LeftValue> leftValue = this->leftExp->evalAs<LeftValue>(runtimeEnv);
    runtimeEnv->interpreter->checkForInterrupts(this->leftExp);
    intrusive_ptr<RightValue> rightValue = this->rightExp->evalAs<RightValue>(runtimeEnv);
    if (leftValue->assignmentNeedsOwnership())
        leftValue->obtainOwnership();
    leftValue->assign(rightValue, this->rightExp->getBegin(), this->rightExp->getEnd(), runtimeEnv);
}

Now I fear there may be some "strange" situations in which nasty things may occur:

define HEAD(ref L) L := L[1]; return L; enddefine;
L := [1,2];
L[2] := HEAD(ref L); --> asking for trouble!

With my modified CoCoA-5 this produces:

--> ERROR: Expecting type LIST, MAT or MATRIXROW, but found type INT
--> L[2] := HEAD(L); --> asking for ...
--> ^

Not so helpful, but I had feared a crash or memory corruption.

1. evaluate blah
2. check that L is indexable and that i is a valid index; if so, then assign.

Not sure what the actual semantics are...

A potential disadvantage of my proposed semantics is that if the RHS is expensive to evaluate, and the LHS is "obviously wrong" then the user must wait for the evaluation of RHS to finish before discovering the error.

What should happen with this input?

>>> J := 1;
>>> define MakeRecord(ref A) A := record[]; return 1; enddefine;
>>> J.xyz := MakeRecord(J);

Currently it complains:

--> ERROR: Expecting type RECORD, but found type INT
--> J.xyz := MakeRecord(J);
--> ^

I am inclined to think that a user who writes an assignment LHS := RHS; where evaluating RHS may change the structure of LHS should accept whatever CoCoA-5 chooses to do... but CoCoA-5 should not SEGV, or corrupt memory or do anything else "nasty": it should either do something "legal" or return a proper CoCoA error.

John Abbott wrote:

I am inclined to think that a user who writes an assignment LHS := RHS; where evaluating RHS may change the structure of LHS should accept whatever CoCoA-5 chooses to do...

Michael Abshoff used to say "you can't prevent the user to shoot himself in the foot".

PS with my old CoCoA I get the same errors you wrote.

Yes, we cannot (and probably should not) stop the user from "shooting himself in the foot".
But CoCoA-5 should never crash (SEGV, or other naughty memory access).

1. check that LHS is writable (valid index, etc)
2. evaluate RHS
3. check again that LHS is writable, and then write the value.

I would hope that checking writability is cheap...

John Abbott wrote:

I would hope that checking writability is cheap...

We will make some checks.
I want to design some speed tests mechanism.
(Cannot really be based on the current test examples because they are for testing correctedness, and effectively expansible at any time)

My proposal in comment 11 is bad because, for instance, the computation of an index may be lengthy or may have side-effects. The user would be surprised to find the index computed twice.

1. check LHS, and cache the index values (if any)
2. evaluate RHS
3. check existence/writability of LHS using the cached indexes

It seems that the interpreter may already do something similar to this, because my tests gave errors (but the error messages were not very helpful...)

NOTE a naughty user could write something like L[expr1] := expr2 where expr1 has a side-effect changing L, and expr2 has a side-effect changing the way expr1 is evaluated. Hopefully Giovanni had already thought of this!

It does not really matter how we evaluate LHS := RHS.
Either side could be expensive to evaluate. Publicly we should say that the order of evaluation is not rigidly specified -- this lets us change it in the future. Anyway, it is rather risky writing code which relies on order of evaluation inside a single expression.

Anyway, my suggestion in comment 13 is reasonable (and seems to be what the interpreter actually does, based on a few tests).

I think I have found a situation where my simple idea in comment 6 causes trouble...

/**/ L := [2,3,1];
/**/ sorted(L);
[1,2,3];
/**/ L;
[1,2,3]; // OUCH!!??!!

Boohoo!!

Note: JAA has no idea how to fix this :-( But it is a terrible SLUG.