discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Reassignment rules

R
Ronaldo
Sun, Jun 18, 2017 3:37 PM

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.

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.
MK
Marius Kintel
Sun, Jun 18, 2017 4:26 PM

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 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
IO
Ian Oliver
Sun, Jun 18, 2017 5:16 PM

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.

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.
R
Ronaldo
Sun, Jun 18, 2017 9:31 PM

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.

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.
R
Ronaldo
Sun, Jun 18, 2017 9:34 PM

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.

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.
TP
Torsten Paul
Sun, Jun 18, 2017 9:46 PM

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.

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.
R
Ronaldo
Sun, Jun 18, 2017 10:00 PM

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.

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.