Plans to change variable behavior ?

classic Classic list List threaded Threaded
91 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

nophead
Perhaps add a syntax for setting a default that can be overridden but only once. E.g.

length ?= 20;   // Establishes a default.

length = 30;   // Allowed as is -Dlength = 30

length = 29;  // error



On 19 September 2014 15:08, MichaelAtOz <[hidden email]> wrote:
Note that variables within use<> and/or include<> (I can't recall the subtle
different details ATM) have issues with -D.

IIRC you need to assign a var a=0; before the include<> iif that var is
initialised in the include and you wish to use it in a later assignment to
override the default (& hence particularly a -D assignment)

Not saying that is ideal, but backwards wise...



-----
Unless specifically shown otherwise above, this is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :)
.s. The `´ key on my keyboard is soradically roblematic when I ress it, reciitating erceived missellings

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/
--
View this message in context: http://forum.openscad.org/Plans-to-change-variable-behavior-tp9647p9720.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

stonysmith
In reply to this post by Oskar
Two cents:  I want to construct iterative models of trees (plants).

1) Place a trunk by computing the position for the base of a cylinder and a (random) height for the top of the trunk.
2) From that spot, compute 2-6 major branches that start at the base of the trunk and terminate at some point higher in space, again with random angle position and random lengths.
3) Then compute mid-size branches repeating step 2

I would be happy to discuss some proposed solution in another thread.. my point for THIS thread is that interactive, "run time" variable assignment would make coding the process required above simpler.

I mean ZERO offense to anyone on either side of the discussion, but I'd like to respectfully disagree that OpenSCAD should only be a "fixed definition of a specific geometry". (I agree that it IS currently that way, but I would like to see that evolve)  There are a number of places where LET A=A+1 would provide cleaner (easier to read, better documented) code.  Plus, the ability to actually generate randomized geometries that build upon themselves would be helpful.
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

nophead
Generating trees is much easier with recursion than it is with iteration as they are naturally recursive in nature.  There have been examples posted on this list.

On 19 September 2014 16:15, stonysmith <[hidden email]> wrote:
Two cents:  I want to construct iterative models of trees (plants).

1) Place a trunk by computing the position for the base of a cylinder and a
(random) height for the top of the trunk.
2) From that spot, compute 2-6 major branches that start at the base of the
trunk and terminate at some point higher in space, again with random angle
position and random lengths.
3) Then compute mid-size branches repeating step 2

I would be happy to discuss some proposed solution in another thread.. my
point for THIS thread is that interactive, "run time" variable assignment
would make coding the process required above simpler.

I mean ZERO offense to anyone on either side of the discussion, but I'd like
to respectfully disagree that OpenSCAD should only be a "fixed definition of
a specific geometry". (I agree that it IS currently that way, but I would
like to see that evolve)  There are a number of places where LET A=A+1 would
provide cleaner (easier to read, better documented) code.  Plus, the ability
to actually generate randomized geometries that build upon themselves would
be helpful.



--
View this message in context: http://forum.openscad.org/Plans-to-change-variable-behavior-tp9647p9723.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

Whosawhatsis
In reply to this post by nophead
I like this idea, though I would add that it should set a variable only if it is not set anywhere else (default value) so that you can put user-configurable variables at the top and set defaults at the bottom of the file. So it could also look like this:

length = 30;   // Allowed as is -Dlength = 30

length = 29;  // error

length ?= 20;   // sets length only if the other lines are omitted.

On Friday, September 19, 2014 at 10:31 AM, nop head wrote:
Perhaps add a syntax for setting a default that can be overridden but only once. E.g.

length ?= 20;   // Establishes a default.

length = 30;   // Allowed as is -Dlength = 30

length = 29;  // error



On 19 September 2014 15:08, MichaelAtOz <[hidden email]> wrote:
Note that variables within use<> and/or include<> (I can't recall the subtle
different details ATM) have issues with -D.

IIRC you need to assign a var a=0; before the include<> iif that var is
initialised in the include and you wish to use it in a later assignment to
override the default (& hence particularly a -D assignment)

Not saying that is ideal, but backwards wise...



-----
Unless specifically shown otherwise above, this is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :)
.s. The `´ key on my keyboard is soradically roblematic when I ress it, reciitating erceived missellings

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/
--
View this message in context: http://forum.openscad.org/Plans-to-change-variable-behavior-tp9647p9720.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

nophead
The problem with it being at the bottom is that any uses of length would not see it. Also it is nice to see what is expected to be overridden at the top of a file.

On 19 September 2014 16:56, whosawhatsis <[hidden email]> wrote:
I like this idea, though I would add that it should set a variable only if it is not set anywhere else (default value) so that you can put user-configurable variables at the top and set defaults at the bottom of the file. So it could also look like this:

length = 30;   // Allowed as is -Dlength = 30

length = 29;  // error

length ?= 20;   // sets length only if the other lines are omitted.

On Friday, September 19, 2014 at 10:31 AM, nop head wrote:
Perhaps add a syntax for setting a default that can be overridden but only once. E.g.

length ?= 20;   // Establishes a default.

length = 30;   // Allowed as is -Dlength = 30

length = 29;  // error



On 19 September 2014 15:08, MichaelAtOz <[hidden email]> wrote:
Note that variables within use<> and/or include<> (I can't recall the subtle
different details ATM) have issues with -D.

IIRC you need to assign a var a=0; before the include<> iif that var is
initialised in the include and you wish to use it in a later assignment to
override the default (& hence particularly a -D assignment)

Not saying that is ideal, but backwards wise...



-----
Unless specifically shown otherwise above, this is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :)
.s. The `´ key on my keyboard is soradically roblematic when I ress it, reciitating erceived missellings

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/
--
View this message in context: http://forum.openscad.org/Plans-to-change-variable-behavior-tp9647p9720.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

MichaelAtOz
Administrator
I know it is programatically easier to stick -Dvar=val at the bottom, but what about sticking them at the top. Then;


param1=20; // inserted by -D
// .scad code starts here
myVar = ? (param1 = undef) 10 : param1;

OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain;
to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

Whosawhatsis
In reply to this post by nophead
Actually, the way OpenSCAD currently works, you can override all of your variables at the bottom of the file, and that will take precedence over all earlier uses. Putting the defaults at the top, above the lines that are intended to be modified by the user, just makes the lines that you want the user to modify harder for them to find, though you could put it directly below those lines if you prefer. The point is that the ?= assignment should not override a variable that has already been set in the usual way, which is would otherwise.

Currently:

echo(length); //ECHO: 20
length = 30;
length = 20; 
echo(length); //ECHO: 20

What I'm suggesting:

echo(length); //ECHO: 30
echo(width);  //ECHO: 25
length = 30;
length ?= 20; 
width ?= 25; 
echo(length); //ECHO: 30
echo(width);  //ECHO: 25

On Friday, September 19, 2014 at 12:00 PM, nop head wrote:

The problem with it being at the bottom is that any uses of length would not see it. Also it is nice to see what is expected to be overridden at the top of a file.

On 19 September 2014 16:56, whosawhatsis <[hidden email]> wrote:
I like this idea, though I would add that it should set a variable only if it is not set anywhere else (default value) so that you can put user-configurable variables at the top and set defaults at the bottom of the file. So it could also look like this:

length = 30;   // Allowed as is -Dlength = 30

length = 29;  // error

length ?= 20;   // sets length only if the other lines are omitted.

On Friday, September 19, 2014 at 10:31 AM, nop head wrote:
Perhaps add a syntax for setting a default that can be overridden but only once. E.g.

length ?= 20;   // Establishes a default.

length = 30;   // Allowed as is -Dlength = 30

length = 29;  // error



On 19 September 2014 15:08, MichaelAtOz <[hidden email]> wrote:
Note that variables within use<> and/or include<> (I can't recall the subtle
different details ATM) have issues with -D.

IIRC you need to assign a var a=0; before the include<> iif that var is
initialised in the include and you wish to use it in a later assignment to
override the default (& hence particularly a -D assignment)

Not saying that is ideal, but backwards wise...



-----
Unless specifically shown otherwise above, this is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :)
.s. The `´ key on my keyboard is soradically roblematic when I ress it, reciitating erceived missellings

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/
--
View this message in context: http://forum.openscad.org/Plans-to-change-variable-behavior-tp9647p9720.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

Whosawhatsis
In reply to this post by MichaelAtOz
Assuming what you meant was:

myVar = (param1 == undef) ? 10 : param1;

It would be a lot more useful if you didn't have to have different names for myVar and param1, but if you try to set param1 using that method, it will always be undefined at the point that statement is evaluated.

On Friday, September 19, 2014 at 5:26 PM, MichaelAtOz wrote:

I know it is programatically easier to stick -Dvar=val at the bottom, but
what about sticking them at the top. Then;


param1=20; // inserted by -D
// .scad code starts here
myVar = ? (param1 = undef) 10 : param1;





-----
Unless specifically shown otherwise above, this is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :)
.s. The `´ key on my keyboard is soradically roblematic when I ress it, reciitating erceived missellings

The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/
--
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

MichaelAtOz
Administrator
give a guy a break re typo.

I think I have the answer to my earlier point re include<> which is where -D breaks down.

OpenSCAD stick the -D variable, both at the top (possibly with = undef), and at the bottom (=value).

So;

with -DyourVar=10;
----------------------------------------------------------------------
yourVar=undef; // or 10 doesn't matter. Inserted by -D
include <something> // inside i=1;
//...
yourVar=20; // default, or for testing in GUI
//...
i=yourVar; // without the first line, this would error
//...
yourVar=10; // inserted by -D, overrides all above. Will result in i=10
----------------------------------------------------------------------
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain;
to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

Alan Cox
In reply to this post by Gaston
> With these measures the screw will withstand the case when screwed in as it is too long. The solution is to recomputed the height, without reassignment (i.e. immutable) this would require:
>
> pcb_foot_h= (screw_length>pcb_foot_height) ? screw_length : pcb_foot_height;
>
>  
>
> while mutuable would be:
>
> pcb_foot_height= (screw_length>pcb_foot_height) ? screw_length : pcb_foot_height;
>

Which is a nonsensical statement to anyone but a sequentially damaged
computer programmer.

> IMO the first reduces readability because a second variable needs to be introduced for the exact same purpose.

It's got a quite different purpose. One of them is your actual foot
height, the other is a limiting foot height.

And you could equally make pcb_foot_height a function(), at which point it
would do exactly what you wanted.

> With scope the story is quite similar. When code lines depend on a same condition (and this is even worse when it comes to complex ones) you will never write:
>
> If(condition) action1;
>
> If(condition) action2;
>
> If(condition) action3;
>
> If(condition) action4;

Examples would be helpful ?

Alan
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

laird
In reply to this post by Gaston
The thing to remember in OpenSCAD is that there's no sequence, only structure.

That is, if you write:

a=1;
echo(a);
a=2;
echo(a);
a=3;
echo(a);

You get:

ECHO: 3
ECHO: 3
ECHO: 3

This is because there are three assignments to a, and the last one wins (a very slight exception to 'no sequence'), so a is 3 everywhere in the code.

So if you need to do something iterative, you have to either express it functionally (e.g. recursion, list comprehension, rethinking the algorithm to not be iterative) or you have to do it outside of OpenSCAD and them use that to generate OpenSCAD which then renders non-iteratively.

When I have to do this, I use Solid Python. For example, doing iterative graph layout is easy in Python, then when the iteration is done I have it generate an OpenSCAD representation of the graph. The combination of tools really works quite nicely.
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

Gaston
In reply to this post by kintel
Marius Kintel wrote:

        > Note that there is a subtle difference between _mutable_ and _reassignable_:

        > All values in OpenSCAD are immutable, but we do allow reassignment. However, the reassignment semantics in OpenSCAD are so confusing (and only allowed due to the -D cmd-line parameter) that we’re > thinking about disallowing it completely in the future. The core issue being that intuitively sound reassignment semantics imply sequential execution.

Yes, it is the behavior of OpenSCAD in this area is which made me call it "bug" and did hide from myself that it could be meant to be a PFPL. I still see it as a "language bug", despite the fact that it was probably for use with libraries. The main question (assuming all issues can be eliminated) is if the immutability must be retained or not. If it must be kept then the next question is if it has to be absolutely kept, or "only" in regard of modules (not functions). In that latter case one could allow value changes up to the first module call.

Anyway the biggest improvement suggestion was anyway the out of scope assignment, i.e. the assignment to a global variable inside a { }. With some analysis and taking into account the comments so far I would suggest:

1. Assuming that in the current version assign() is still active for local variables and direct assignment to blocks are not yet allowed
2. Any assignment within a { } block will be redirected to the blocks main scope. The main scope of a block is the module for any block inside a module and the global scope for any other block
3. Assignments meant to be local to the current and lower blocks need to be preceded by the local keyword

i.e.

global_var=1

if(global_var == 1)
{
   also_global_var=2;
}

Module someModule(v) // v like module local var
{
  module_local_var=3;
  if(module_local_var==v)
  {
     also_module_local_var=4;
     local local_var=5;
    // all variables accessible here
   {
    // all variables accessible here   }
  }
 // all variables accessible except local_var
}

// global_var and also_global_var accessible



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

nophead
I don't know why you want to break normal scope rules. Variables defined in local scopes don't leak out of it in any language I know and for good reason.

Your also_global_var is only defined if global_var == 1 so any further use of it would have to be guarded.

On 22 September 2014 14:07, Gaston Gloesener <[hidden email]> wrote:
Marius Kintel wrote:

        > Note that there is a subtle difference between _mutable_ and _reassignable_:

        > All values in OpenSCAD are immutable, but we do allow reassignment. However, the reassignment semantics in OpenSCAD are so confusing (and only allowed due to the -D cmd-line parameter) that we’re   > thinking about disallowing it completely in the future. The core issue being that intuitively sound reassignment semantics imply sequential execution.

Yes, it is the behavior of OpenSCAD in this area is which made me call it "bug" and did hide from myself that it could be meant to be a PFPL. I still see it as a "language bug", despite the fact that it was probably for use with libraries. The main question (assuming all issues can be eliminated) is if the immutability must be retained or not. If it must be kept then the next question is if it has to be absolutely kept, or "only" in regard of modules (not functions). In that latter case one could allow value changes up to the first module call.

Anyway the biggest improvement suggestion was anyway the out of scope assignment, i.e. the assignment to a global variable inside a { }. With some analysis and taking into account the comments so far I would suggest:

1. Assuming that in the current version assign() is still active for local variables and direct assignment to blocks are not yet allowed
2. Any assignment within a { } block will be redirected to the blocks main scope. The main scope of a block is the module for any block inside a module and the global scope for any other block
3. Assignments meant to be local to the current and lower blocks need to be preceded by the local keyword

i.e.

global_var=1

if(global_var == 1)
{
   also_global_var=2;
}

Module someModule(v) // v like module local var
{
  module_local_var=3;
  if(module_local_var==v)
  {
     also_module_local_var=4;
     local local_var=5;
    // all variables accessible here
   {
    // all variables accessible here   }
  }
 // all variables accessible except local_var
}

// global_var and also_global_var accessible



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

Gaston

nop head wrote:

 

 

Ø  I don't know why you want to break normal scope rules. Variables defined in local scopes don't leak out of it in any language I know and for good reason.

While there is no such thing as “normal scoping”, what I set here, is what you would call “normal scoping” I guess, as it is what most languages do. Usually in languages there are strong and weak scope boundaries, and my proposal does not more than setting those..

 

Ø  Your also_global_var is only defined if global_var == 1 so any further use of it would have to be guarded.

 

My apologies for me misleading you. As I said initially I am used to these matters and I sometime seem to forget that this is not the main activity  area of the members of this forum. Of course you are right, but when speaking of language design in a specific area the actual function of an example does not matter. I am only focusing on variable scope of the language here.

 

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of nop head
Sent: Monday, September 22, 2014 3:17 PM
To: [hidden email]
Subject: Re: [OpenSCAD] Plans to change variable behavior ?

 

I don't know why you want to break normal scope rules. Variables defined in local scopes don't leak out of it in any language I know and for good reason.

Your also_global_var is only defined if global_var == 1 so any further use of it would have to be guarded.

 

On 22 September 2014 14:07, Gaston Gloesener <[hidden email]> wrote:

Marius Kintel wrote:

        > Note that there is a subtle difference between _mutable_ and _reassignable_:

        > All values in OpenSCAD are immutable, but we do allow reassignment. However, the reassignment semantics in OpenSCAD are so confusing (and only allowed due to the -D cmd-line parameter) that we’re   > thinking about disallowing it completely in the future. The core issue being that intuitively sound reassignment semantics imply sequential execution.

Yes, it is the behavior of OpenSCAD in this area is which made me call it "bug" and did hide from myself that it could be meant to be a PFPL. I still see it as a "language bug", despite the fact that it was probably for use with libraries. The main question (assuming all issues can be eliminated) is if the immutability must be retained or not. If it must be kept then the next question is if it has to be absolutely kept, or "only" in regard of modules (not functions). In that latter case one could allow value changes up to the first module call.

Anyway the biggest improvement suggestion was anyway the out of scope assignment, i.e. the assignment to a global variable inside a { }. With some analysis and taking into account the comments so far I would suggest:

1. Assuming that in the current version assign() is still active for local variables and direct assignment to blocks are not yet allowed
2. Any assignment within a { } block will be redirected to the blocks main scope. The main scope of a block is the module for any block inside a module and the global scope for any other block
3. Assignments meant to be local to the current and lower blocks need to be preceded by the local keyword

i.e.

global_var=1

if(global_var == 1)
{
   also_global_var=2;
}

Module someModule(v) // v like module local var
{
  module_local_var=3;
  if(module_local_var==v)
  {
     also_module_local_var=4;
     local local_var=5;
    // all variables accessible here
   {
    // all variables accessible here   }
  }
 // all variables accessible except local_var
}

// global_var and also_global_var accessible

 


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

nophead


On 22 September 2014 14:55, Gaston Gloesener <[hidden email]> wrote:

nop head wrote:

 

 

Ø  I don't know why you want to break normal scope rules. Variables defined in local scopes don't leak out of it in any language I know and for good reason.

While there is no such thing as “normal scoping”, what I set here, is what you would call “normal scoping” I guess, as it is what most languages do. Usually in languages there are strong and weak scope boundaries, and my proposal does not more than setting those..

In curly bracket languages each pair of brackets delineates a scope and things defined inside are local to that scope. I can' think of any exceptions to that rule.

What is an example of a " weak scope boundary"?

In Python you can define a global inside a block but that is explicit and of no benefit to a language like OpenScad.

 

Ø  Your also_global_var is only defined if global_var == 1 so any further use of it would have to be guarded.

 

My apologies for me misleading you. As I said initially I am used to these matters and I sometime seem to forget that this is not the main activity  area of the members of this forum. Of course you are right, but when speaking of language design in a specific area the actual function of an example does not matter. I am only focusing on variable scope of the language here.


It might be just an artificial example but by allowing global variables to be conditionally defined you are allowing such a possibility and it is much better that the language does not allow such things. The current scheme of doing it with ?: is better because it doesn't allow things like this but can do it like this:

also_global_var = global_var == 1 ? 2 : <something else>;

also_global_var is always defined, which is clearer and less error prone. 
 

 

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of nop head
Sent: Monday, September 22, 2014 3:17 PM
To: [hidden email]
Subject: Re: [OpenSCAD] Plans to change variable behavior ?

 

I don't know why you want to break normal scope rules. Variables defined in local scopes don't leak out of it in any language I know and for good reason.

Your also_global_var is only defined if global_var == 1 so any further use of it would have to be guarded.

 

On 22 September 2014 14:07, Gaston Gloesener <[hidden email]> wrote:

Marius Kintel wrote:

        > Note that there is a subtle difference between _mutable_ and _reassignable_:

        > All values in OpenSCAD are immutable, but we do allow reassignment. However, the reassignment semantics in OpenSCAD are so confusing (and only allowed due to the -D cmd-line parameter) that we’re   > thinking about disallowing it completely in the future. The core issue being that intuitively sound reassignment semantics imply sequential execution.

Yes, it is the behavior of OpenSCAD in this area is which made me call it "bug" and did hide from myself that it could be meant to be a PFPL. I still see it as a "language bug", despite the fact that it was probably for use with libraries. The main question (assuming all issues can be eliminated) is if the immutability must be retained or not. If it must be kept then the next question is if it has to be absolutely kept, or "only" in regard of modules (not functions). In that latter case one could allow value changes up to the first module call.

Anyway the biggest improvement suggestion was anyway the out of scope assignment, i.e. the assignment to a global variable inside a { }. With some analysis and taking into account the comments so far I would suggest:

1. Assuming that in the current version assign() is still active for local variables and direct assignment to blocks are not yet allowed
2. Any assignment within a { } block will be redirected to the blocks main scope. The main scope of a block is the module for any block inside a module and the global scope for any other block
3. Assignments meant to be local to the current and lower blocks need to be preceded by the local keyword

i.e.

global_var=1

if(global_var == 1)
{
   also_global_var=2;
}

Module someModule(v) // v like module local var
{
  module_local_var=3;
  if(module_local_var==v)
  {
     also_module_local_var=4;
     local local_var=5;
    // all variables accessible here
   {
    // all variables accessible here   }
  }
 // all variables accessible except local_var
}

// global_var and also_global_var accessible

 


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

Gaston

Ø  In curly bracket languages each pair of brackets delineates a scope and things defined inside are local to that scope. I can' think of any exceptions to that rule.

Don’t mixup things. There is no explicit variable declaration (like in “C” or others) in OpenSCAD. Most curly bracket languages I know have only weak scopes, you have  to declare a variable explicitely in that scape for it to be scoped, else it will extend to the next upper scope.

int a=1;

if(somcecondition)
{
int a=10;  // is local
}

while

int a=1;

if(somcecondition)
{
a=10;  // modifies the global variable
}

So explicit scoping is required -> weak scope boundary

 

Ø  In Python you can define a global inside a block but that is explicit and of no benefit to a language like OpenScad.

 

Nope, in python you only need to specify global inside a function, not every block. I agreed already that one could keep the strong module boundary in OpenSCAD for modules. Do no globals from modules.

 

 

 

 


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

laird
" you have  to declare a variable explicitly in that scape for it to be scoped, else it will extend to the next upper scope."

I can't think of any languages that do this. In C, C++, etc., identifiers (variables, functions) declared inside curly braces exist only within the curly braces. And while some languages (e.g. Python) have slightly weirder scoping rules, none of them leak identity definition to "next upper scope". Some of them define scope boundaries at the function/class level, instead of the "curly braces", but that definition is still "strong", not "weak".

In your example:

int a=1;

if(somcecondition)
{
int a=10;  // is local
}

In C/C++, the two 'a' variables are unrelated. It might as well be written:

int a=1;

if(somcecondition)
{
int b=10;  // is local
}

For what it's worth, the main reason that I care about scoping is that the lack of scoping is making my project extremely difficult because I have to rename all 'globals' ("variables" and methods and functions) in all included files to avoid collisions between OpenSCAD modules written by many different people that are pulled into a single assembly. Scoping would help in that developers could then have a mechanism to encapsulate "variables" and modules and functions such that only a few well-defined IDs would be exposed and need to be renamed.

Of course, real namespaces would be a huge help, since it would presumably mean that I wouldn't have to worry about collisions between utility functions/modules written by different people, version collisions, etc., because each one would be in its own namespace, and I could explicitly do what I need to do in the overall assembly. But namespaces require scoping to make any sense.


On Mon, Sep 22, 2014 at 11:16 AM, Gaston Gloesener [via OpenSCAD] <[hidden email]> wrote:

Ø  In curly bracket languages each pair of brackets delineates a scope and things defined inside are local to that scope. I can' think of any exceptions to that rule.

Don’t mixup things. There is no explicit variable declaration (like in “C” or others) in OpenSCAD. Most curly bracket languages I know have only weak scopes, you have  to declare a variable explicitely in that scape for it to be scoped, else it will extend to the next upper scope.

int a=1;

if(somcecondition)
{
int a=10;  // is local
}

while

int a=1;

if(somcecondition)
{
a=10;  // modifies the global variable
}

So explicit scoping is required -> weak scope boundary

 

Ø  In Python you can define a global inside a block but that is explicit and of no benefit to a language like OpenScad.

 

Nope, in python you only need to specify global inside a function, not every block. I agreed already that one could keep the strong module boundary in OpenSCAD for modules. Do no globals from modules.

 

 

 

 


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


If you reply to this email, your message will be added to the discussion below:
http://forum.openscad.org/Plans-to-change-variable-behavior-tp9647p9760.html
To unsubscribe from Plans to change variable behavior ?, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

nophead
In reply to this post by Gaston
Yes but we have already said OpenScad variables are immutable so

On 22 September 2014 16:16, Gaston Gloesener <[hidden email]> wrote:

Ø  In curly bracket languages each pair of brackets delineates a scope and things defined inside are local to that scope. I can' think of any exceptions to that rule.

Don’t mixup things. There is no explicit variable declaration (like in “C” or others) in OpenSCAD. Most curly bracket languages I know have only weak scopes, you have  to declare a variable explicitely in that scape for it to be scoped, else it will extend to the next upper scope.

int a=1;

if(somcecondition)
{
int a=10;  // is local
}

while

int a=1;

if(somcecondition)
{
a=10;  // modifies the global variable
}

So explicit scoping is required -> weak scope boundary

 

 
Yes but we have already said OpenScad variables are immutable so although you can of course use variables already defined outside the scope you cannot change them, simply because you can't change any. Defining new ones inside a scope and expecting it to leak out is totally different and not how other languages behave.

Ø  In Python you can define a global inside a block but that is explicit and of no benefit to a language like OpenScad.

 

Nope, in python you only need to specify global inside a function, not every block. I agreed already that one could keep the strong module boundary in OpenSCAD for modules. Do no globals from modules.

  

 

 

 


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

laird
Scoping isn't about 'variables' it's about 'identity'. Variables, functions and modules are just examples of things with identity.

On Mon, Sep 22, 2014 at 11:48 AM, nophead [via OpenSCAD] <[hidden email]> wrote:
Yes but we have already said OpenScad variables are immutable so



Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

rickan
In reply to this post by nophead
I really feel I should add my vote against these silly immutable variables.

<rant>
It really is silly, it makes some very, very useful things that are trivial to do with regular variables seemingly impossible in openscad, and I can't imagine it's good for beginning programmers or people who do it infrequently. It seems obvious what if you want OpenSCAD to be as widely adopted as possible, you will drop this immutable variable ideology. Find some other way to advocate the functional programming ideology.

I'm retired from doing programming for a living, and I've never been impressed with the "problems" that functional programming is supposed to be a solution for, nor is it apparent to me that it's been widely adopted to solve those "problems".

I'm sure these ideas have already been thoroughly hashed in this thread (which I don't have the patience to read) -- this is just my vote.

P.S. I'm a Perl programmer when given a choice because the Perl ideology is "There is more than one way to do it" and I can choose the way that's best for me, for each of projects of widely various character, from what seems to be a very nearly complete set of tools including some which impose programming restrictions for those who seem to need them. I've never found it wanting and can't recall the language interposing itself as part of the problem the way I can other other languages.

P.P.S. I'm certainly NOT advocating for making the OpenSCAD language as universal as Perl. I'm not very experienced with it and probably never will be, but it seems to be more than adequate for solid modelling except for those silly...
</rant>
12345