My initial thought was, imperative block could be removed - code in {} in imperative control flow would be in non-imperative context (let's not use associative anymore), but realise that besides sequential execution in imperative code, multi assignment is OK in imperative context, e.g.,
[Imperative]
{
x = 0;
cond = ...
while (x < 100) {
if (cond)
x = x + 1;
else
x = x + 2;
}
}
So if capture list is optional, we have to check (in usage and in compiler implementation) a variable is defined in this imperative block scope or not. If it is defined outside, it shouldn't be modified. To me it is inconvenient.
x = 1;
[Imperative]
{
y = 2;
x = 2; // Invalid
y = 3; // OK
}
If capture list is not optional, it is clear that the value is "copied" to the imperative block:
x = 1;
[Imperative](x)
{
while (x < 100) {
x = x + 1; // OK to assign new value to "x"
}
}
// here x is still 1
The other benefit is to support replication on imperative language block.
The downside is some current workflows will be broken. To mitigate that, if there is an error in code block node, we won't delete all connectors until error gets fixed.
My initial thought was, imperative block could be removed - code in
{}
in imperative control flow would be in non-imperative context (let's not use associative anymore), but realise that besides sequential execution in imperative code, multi assignment is OK in imperative context, e.g.,So if capture list is optional, we have to check (in usage and in compiler implementation) a variable is defined in this imperative block scope or not. If it is defined outside, it shouldn't be modified. To me it is inconvenient.
If capture list is not optional, it is clear that the value is "copied" to the imperative block:
The other benefit is to support replication on imperative language block.
The downside is some current workflows will be broken. To mitigate that, if there is an error in code block node, we won't delete all connectors until error gets fixed.
@pboyer what do you think?