Reassignment rules in OpenSCAD are quite disturbing. From an Ian's code
recently published here I found it can be even more disturbing.
function F(a,b) =
let( c = b,
b = a+b )
[a,b,c];
echo(F(3,10));
What would you expect from that code? An error, a warning? No, the same
outcome of any imperative language.
What is the reasoning behind this?
--
View this message in context: http://forum.openscad.org/Reassignment-rules-tp21718.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Jun 18, 2017, at 11:37, Ronaldo rcmpersiano@gmail.com wrote:
Reassignment rules in OpenSCAD are quite disturbing. From an Ian's code
recently published here I found it can be even more disturbing.
function F(a,b) =
let( c = b,
b = a+b )
[a,b,c];
echo(F(3,10));
What would you expect from that code? An error, a warning? No, the same
outcome of any imperative language.
This particular example is well-defined and should produce [3, 13, 10].
No reassignment is involved; you’re just opening a new scope and introducing two new variables that happen to shadow the function parameters names.
If your confusion is let(): let() explicitly assigns in sequential order and allows subsequent expressions to utilize already initialized values.
-Marius
On 2017-06-18 08:37, Ronaldo wrote:
Reassignment rules in OpenSCAD are quite disturbing. From an Ian's code
recently published here I found it can be even more disturbing
What is disturbing in my example?
TBH I'm starting to get the hang of OpenSCADs scoping rules but had to
play with quite a few contrived examples to get my head clear on some
corner cases.
That a variable takes its value from the last definition but the
declaration is done where first defined can be "interesting" at times.
For example stare at this and work out what will happen when "run".
b = 4;
a = 3;
c = 5;
a = b+c;
I've also see that values can be passed down to functions without them
being listed in the arguments at definition time.
For instance, this prints "5".
a = 3;
module test () {
echo(a);
}
test (a=5);
Very handy with special variables, which reduce "clutter" a lot when
passing variables down through lots of levels of functions.
Consider the following code:
/
module A(){ // context 1
a = 3;
b = 10;
{ // context 2
c = b;
b = a+b;
echo(a,b,c);
}
}
A();
/
Acording to Kintel, /b = a+b/ should not be considered a reassignment
because a new scope has been opened and the context 2 variable b is
shadowing the name of a variable in context 1. But, this code generates a
warning: /Ignoring unknown variable 'b'/ that is not issued when we exclude
the assignment /b = a+b/. So,
--
View this message in context: http://forum.openscad.org/Reassignment-rules-tp21718p21721.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I don't see any significant distinction between the code of function F of my
first message and the module A of the second.
--
View this message in context: http://forum.openscad.org/Reassignment-rules-tp21718p21722.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
This is the "Anonymous scopes are not considered scopes" part in
the documentation
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Scope_of_variables
Which I think is basically needed to not break existing scripts.
I guess changing that kind of scoping behavior would need some
marker in the script telling the evaluation engine to use the
updated/fixed logic.
ciao,
Torsten.
Thank you, Torsten, to clarify that. In fact, changing the definition of A()
to create a second "real" scope, it works according Kintel's explanation:
module A(){ // context 1
a = 3;
b = 10;
if(true) { // context 2
c = b;
b = a+b;
echo(a=a,b=b,c=c);
}
echo(b=b);
}
A();
--
View this message in context: http://forum.openscad.org/Reassignment-rules-tp21718p21724.html
Sent from the OpenSCAD mailing list archive at Nabble.com.