You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
No description provided.
The text was updated successfully, but these errors were encountered: