Plans to change variable behavior ?

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

Plans to change variable behavior ?

Gaston Gloesener

Hello,

 

I am currently developing a 3D printable case for some for an electronic device with many connections to the outside. The case is highly configurable by variables and I am coming to a point where the variable concept used in OpenSCAD becomes a real pain.

 

Especially the fact that variables cannot be set inside an if statement. And yes I know the C like cond?true-value:false-value expression and I am using it. But at this stage using this syntax would require several levels of “?” and is very error prone.

 

For example the code would adjust certain features of the case so that the screw length can be accommodated so that it is sure that no screw withstands the case. And then even how this is done can be configured by a variable. This requires several conditions and many variable assignments which each will repeat the same conditions. Not only does it become difficult to read, also every change in a condition will have to be done many times. Adding conditions to only some of these would be easy with an additional “if” at some point inside the first but requiring extreme care in the current version.

 

I understand that the problem comes from the fact that expressions are evaluated at compile time (according to the documentation) rather than execution time. But my understanding is that this is only part of the truth as expressions seem at other places well to be evaluated at execution time if for instance they use a for variable.  Another source of troubles (and possibly this is the real trouble source)is that assignments (at least at top level) are internally handled in a separate list which take them out of sync with the other code.

 

I believe that this concept is currently the biggest limitation of OpenSCAD, which nevertheless is a great piece of software.

 

Are there any plans to change this behavior and make variables behave like in other programming languages ?

 

I did only have a quick look at the sources but assuming that expressions can well be evaluated at execution time I would believe this change to have little impact on the code. An assignment “var=expr;” would be transformed into something like super_assign(var,expr);  whick will instead of creating a new context like “assign()” lookup the parent contexts to find the variable and alter it or create it at top level if not found. At a second step one could even introduce the “local” keyword for local variables which would generate a hidden assign, i.e.:

 

module myModule(v)

{

local a=v/2;

local b=v*2;

 

   cube([a,b,a+b]);

}

 

Would be internally represented by:

 

module myModule(v)

{

assign(a=v/2,b=v*2)

{

   cube([a,b,a+b]);

}

}

 

“local” could be used inside any { } and must be the first statement(s) and would render the explicit assign() use obsolete .

 

 

 

 

 

 

 

 

 

 

 

 


_______________________________________________
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'm not an official spokes person, but...

> Are there any plans to change this behavior and make variables behave like in other programming languages ?

I think you will find that's a definite NO.

This gets raised from time to time and is generally reflective with someone not having come to grips with the functional geometry generation aspect of the language.
A for() loop is not iterating as per a standard programming language, it is building a tree of distinct geometric objects, where each geometry is influenced by the loop variable. So for each part of the tree the variable is set at compile time, ie is constant for that branch.

Likewise an if/else is two branches of a tree, only one of which will be kept.

> assignments (at least at top level) are internally handled in a separate list which take them out of sync with the other code.

Not sure what you are getting at??

Some other general points. (and yes it can be difficult, but you build up a different programming mind set and it gets easier)

Use functions to do your " (expr) ? if : else " stuff can help. Pull the logic out of the geometry as much as you can.

Also for complex stuff I found multi line layout helps

a = (bool expr)
     ? (true bool expr)
       ? (true true result)
       : (thue false result)
     : (false result)



Admin - email* me if you need anything, or if I've done something stupid...
* 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 ?

MichaelAtOz
Administrator
In reply to this post by Gaston Gloesener
Also have a look here, you will need to download the development snapshots if you want to use it.
Admin - email* me if you need anything, or if I've done something stupid...
* 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 ?

Joseph Lenox

The important thing to remember in openscad work is that there is no "then", there is only "now".

If you are asking for something that requires "then" you are doing it wrong.

On Sep 17, 2014 7:31 PM, "MichaelAtOz" <[hidden email]> wrote:
Also have a look  here
<https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/List_Comprehensions>  ,
you will need to download the development snapshots if you want to use it.



-----
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-tp9647p9649.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 ?

kintel
Administrator
In reply to this post by Gaston Gloesener
On Sep 17, 2014, at 19:00 PM, Gaston Gloesener <[hidden email]> wrote:

> Are there any plans to change this behavior and make variables behave like in other programming languages ?

Yes, see https://github.com/openscad/openscad/issues/347
I haven’t had time to properly fix this, see e.g. https://github.com/openscad/openscad/blob/master/src/localscope.cc#L58, but it’s definitely on the radar.
Se also this proposal, which partially ties into this issue: https://github.com/openscad/openscad/wiki/OEP3%3A-Function-Values-and-Variable-Scoping-improvements

 -Marius


_______________________________________________
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 Gloesener
In reply to this post by MichaelAtOz

@MichaelAtOz:

>> This gets raised from time to time and is generally reflective with someone not having come to grips with the functional geometry generation aspect of the language.

Well this time the request comes from someone who has built a lot of compilers in his life and did teach compiler building at university in the past. You seem to describe the current behavior as a feature, while I do see it more like a bug. When it comes to language/compiler design the language and the objective of it (geometry generation here) should be handled separately as far as possible. The language should follow general language rules. This is not the case in OpenSCAD as code sequencing and execution sequencing is different. There are very few examples of valid reasons compile time evaluation of expressions (except for optimizations, i.e. optional), especially for languages with control structures. I don't see any of these here.

I really think that this is a design error at the start of the development due to lack of experience with compiler building at that time. This should not be seen as offense to the developer, as every developer, including me of course, comes through such errors, some are easy to fix afterwards, some (like this one) are not.

As by your writings I understand that the compiler is building an execution tree which probably results in a list of geometry module calls with constant parameters which is executed at execution time. So execution time is merely the fact of generating the geometry.

If this is correct I still believe there could be an easy (much easier than moving evaluation to execution time) solution for the behavior but I will have to investigate this further and of course make sure it is compatible with the current behavior.


>> assignments (at least at top level) are internally handled in a
>> separate list which take them out of sync with the other code.
> Not sure what you are getting at??

This is internal OpenSCAD stuff. When the parser encounters an assignment it will add it to a separate list of assignments. This does take the assignment out of the sequence of other code which makes the language sequentially incoherent. In a language (omitting control structures) if A is coded before B, A should be executed before B which is not the case in OpenSCAD due to the assignment list.

> Some other general points. (and yes it can be difficult, but you build up a different programming mind set and it gets easier)

With my background I have to disagree here. Every language has its "mind set" but also should follow general rules. I am regularly programming in many different languages adapting to those mindsets, and basically selecting the language upon it for the required task. Many languages base on the C/C++ mindset (like java, php,...) while others are more or less completely different (like python or lisp) but ALL of them follow the general rules.

As a general rule of thumb a language restriction severity is directly proportional to the potential to increase code complexity. And this potential is huge in this case, but possibly most applications never hit it because they are of lesser complexity (note that this speaks of code complexity, very complex geometries can have low code complexity if they have no or few options)

I agree that formatting can help at some point, but this help is limited. The use of functions is more complex in this context as it can reduce code repetition but may increase complexity of code change at  the other side increasing error risks again. Anyway any of these techniques do only move the point at which complexity is too high, not eliminating it.

For sure I have (and know how) to handle it with the current bahavior for my current project, but would be great if this could be changed in a future release.




_______________________________________________
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 ?

Joseph Lenox
On 09/18/2014 02:29 AM, Gaston Gloesener wrote:
@MichaelAtOz:

This gets raised from time to time and is generally reflective with someone not having come to grips with the functional geometry generation aspect of the language.
Well this time the request comes from someone who has built a lot of compilers in his life and did teach compiler building at university in the past. You seem to describe the current behavior as a feature, while I do see it more like a bug. When it comes to language/compiler design the language and the objective of it (geometry generation here) should be handled separately as far as possible. The language should follow general language rules. This is not the case in OpenSCAD as code sequencing and execution sequencing is different. There are very few examples of valid reasons compile time evaluation of expressions (except for optimizations, i.e. optional), especially for languages with control structures. I don't see any of these here. 

I really think that this is a design error at the start of the development due to lack of experience with compiler building at that time. This should not be seen as offense to the developer, as every developer, including me of course, comes through such errors, some are easy to fix afterwards, some (like this one) are not.

As by your writings I understand that the compiler is building an execution tree which probably results in a list of geometry module calls with constant parameters which is executed at execution time. So execution time is merely the fact of generating the geometry.

If this is correct I still believe there could be an easy (much easier than moving evaluation to execution time) solution for the behavior but I will have to investigate this further and of course make sure it is compatible with the current behavior. 


assignments (at least at top level) are internally handled in a 
separate list which take them out of sync with the other code.
Not sure what you are getting at??
This is internal OpenSCAD stuff. When the parser encounters an assignment it will add it to a separate list of assignments. This does take the assignment out of the sequence of other code which makes the language sequentially incoherent. In a language (omitting control structures) if A is coded before B, A should be executed before B which is not the case in OpenSCAD due to the assignment list.

Some other general points. (and yes it can be difficult, but you build up a different programming mind set and it gets easier)
With my background I have to disagree here. Every language has its "mind set" but also should follow general rules. I am regularly programming in many different languages adapting to those mindsets, and basically selecting the language upon it for the required task. Many languages base on the C/C++ mindset (like java, php,...) while others are more or less completely different (like python or lisp) but ALL of them follow the general rules. 

As a general rule of thumb a language restriction severity is directly proportional to the potential to increase code complexity. And this potential is huge in this case, but possibly most applications never hit it because they are of lesser complexity (note that this speaks of code complexity, very complex geometries can have low code complexity if they have no or few options) 

I agree that formatting can help at some point, but this help is limited. The use of functions is more complex in this context as it can reduce code repetition but may increase complexity of code change at  the other side increasing error risks again. Anyway any of these techniques do only move the point at which complexity is too high, not eliminating it. 

For sure I have (and know how) to handle it with the current bahavior for my current project, but would be great if this could be changed in a future release.
OpenSCAD is not a programming language, it's a HDL similar in scope to VHDL or Verilog's structural mode. Treating it like a programming language (like C/C++/Java/Lisp/PHP/Python), IMHO, is a mistake.  It's NOT A PROGRAMMING LANGUAGE. for() in OpenSCAD works just like for...generate() in VHDL. Modules also work pretty much the same way.

Something I could get behind is a way to define a module so that module is generated procedurally (and the resulting prism could then be added to the main tree). Should be fewer side effects. I know that something on the order of VHDL behavior mode isn't going to work in this domain.

Am I making sense here?
-- 

--Joseph Lenox, BS, MS
I'm an engineer. I solve problems.

_______________________________________________
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 Gloesener
In reply to this post by Joseph Lenox

 

Ø  The important thing to remember in openscad work is that there is no "then", there is only "now".

I think I get what you are trying to tell me, but I was not seeking to understand the language behavior but to changeit. On the other side I believe that your statement is wrong (at least as I interpret it) as “now” is a much more precise moment than “then”, and exactly this “now” moment does not exist at language level. At execution level any execution model is always based on “now”.

 

At language level:

 

A=1;

now(A); // “now” A should be 1 , but is 3

A=2;

now(A); // “now” A should be 2 , but is 3

A=3;

now(A); // “now” A should be 3 , and indeed is 3

 

This is because the compiler creates a list of assigned variables with their assigned expressions, each assignment overwriting the previous one, before executing the actual geometry generation. So the assignment for A is 3 before any now() is “called”.

 

So the code above becomes at execution time:

A=1;

A=2;

A=3;

now(A); // “now” A should be 1 , but is 3

now(A); // “now” A should be 2 , but is 3

now(A); // “now” A should be 3 , and indeed is 3

 

This leads to:

 

A=1;

now(A); // “now” A should be 1 , but is undefined

A=A+1;

now(A); // “now” A should be 2 , but is undefined

A=A+1;

now(A); // “now” A should be 3 , and indeed is undefined

 

As the remembered assignment is “A=A+1” prior to “execution” it cannot be computed as A has no value, only an expression.

 

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Joseph Lenox
Sent: Thursday, September 18, 2014 2:58 AM
To: [hidden email]
Subject: Re: [OpenSCAD] Plans to change variable behavior ?

 

The important thing to remember in openscad work is that there is no "then", there is only "now".

If you are asking for something that requires "then" you are doing it wrong.

On Sep 17, 2014 7:31 PM, "MichaelAtOz" <[hidden email]> wrote:

Also have a look  here
<https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/List_Comprehensions>  ,
you will need to download the development snapshots if you want to use it.



-----
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-tp9647p9649.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 ?

MichaelAtOz
Administrator
In reply to this post by Gaston Gloesener
Gaston Gloesener wrote
Well this time the request comes from someone who has built a lot of compilers in his life and did teach compiler building at university in the past. You seem to describe the current behavior as a feature, while I do see it more like a bug.
I too have built compilers, not a lot, and a learnt a lot at university. Many people here are very versed in language design etc. So you may wish to give some of their responses some consideration.
I really think that this is a design error at the start of the development due to lack of experience with compiler building at that time. This should not be seen as offense to the developer,
I'll let the designer speak for him self when he reads this. As I understand it this is a specific design approach not a bug or design error. It just reflects that you are still NOT getting the intent of this language.
As by your writings I understand that the compiler is building an execution tree
 No it is building a static geometry tree, have a look at the Design/Display... which shows them. They are not executed, the geometry is evaluated.
>> assignments (at least at top level) are internally handled in a
>> separate list which take them out of sync with the other code.
> Not sure what you are getting at??

This is internal OpenSCAD stuff. When the parser encounters an assignment it will add it to a separate list of assignments. This does take the assignment out of the sequence of other code which makes the language sequentially incoherent. In a language (omitting control structures) if A is coded before B, A should be executed before B which is not the case in OpenSCAD due to the assignment list.
Again reflects you not getting the language. As Joseph said there is no 'Then' hence there is no 'before', there only 'is' and 'is not'.
> Some other general points. (and yes it can be difficult, but you build up a different programming mind set and it gets easier)

With my background I have to disagree here. Every language has its "mind set" but also should follow general rules. I am regularly programming in many different languages adapting to those mindsets, and basically selecting the language upon it for the required task. Many languages base on the C/C++ mindset (like java, php,...) while others are more or less completely different (like python or lisp) but ALL of them follow the general rules.
Well, you will learn... Try thinking LISP with constants. Try thinking of OpenSCAD 'variables' as constants.
For sure I have (and know how) to handle it with the current bahavior for my current project, but would be great if this could be changed in a future release.
p.s. There are a number of OpenSCAD offshoots which have gone procedural, you may want to check them out.
Admin - email* me if you need anything, or if I've done something stupid...
* 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 ?

MichaelAtOz
Administrator
p.p.s.

> there only 'is' and 'is not'.

It's very Zen once you understand...
Admin - email* me if you need anything, or if I've done something stupid...
* 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 ?

Joseph Lenox
In reply to this post by Gaston Gloesener
On 09/18/2014 02:48 AM, Gaston Gloesener wrote:

 

Ø  The important thing to remember in openscad work is that there is no "then", there is only "now".

I think I get what you are trying to tell me, but I was not seeking to understand the language behavior but to changeit. On the other side I believe that your statement is wrong (at least as I interpret it) as “now” is a much more precise moment than “then”, and exactly this “now” moment does not exist at language level. At execution level any execution model is always based on “now”.

 

At language level:

 

A=1;

now(A); // “now” A should be 1 , but is 3

A=2;

now(A); // “now” A should be 2 , but is 3

A=3;

now(A); // “now” A should be 3 , and indeed is 3

 

This is because the compiler creates a list of assigned variables with their assigned expressions, each assignment overwriting the previous one, before executing the actual geometry generation. So the assignment for A is 3 before any now() is “called”.

 

So the code above becomes at execution time:

A=1;

A=2;

A=3;

now(A); // “now” A should be 1 , but is 3

now(A); // “now” A should be 2 , but is 3

now(A); // “now” A should be 3 , and indeed is 3

OpenSCAD currently is not executed (as I understand it), but compiled. Consider your example with C++ templates.

This leads to:

 

A=1;

now(A); // “now” A should be 1 , but is undefined

A=A+1;

now(A); // “now” A should be 2 , but is undefined

A=A+1;

now(A); // “now” A should be 3 , and indeed is undefined

 

As the remembered assignment is “A=A+1” prior to “execution” it cannot be computed as A has no value, only an expression.

 

 

And this is why VHDL doesn't have variables outside of behavioral mode. I think that the current design of OpenSCAD, which is similar to VHDL structural (or concurrent), is generally correct for this domain.

Additionally, any changes to how identifiers behave would need to be handled in a way that is at least marginally backwards-compatible. I don't have a real problem with "variables" in this system, but I would prefer them to be constrained to an area that is always guaranteed to be procedurally generated (as you programmers expect), but aren't dependent on anything outside of the module (so existing behavior is maintained).

http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html#_Toc526061366
-- 
--Joseph Lenox, BS, MS
I'm an engineer. I solve problems.

_______________________________________________
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
In reply to this post by MichaelAtOz
>Many languages base on the C/C++ mindset (like java, php,...) while others are more or less completely different (like python or lisp) but ALL of them follow the general rules.

You don't mention any pure functional languages or purely declarative languages, which is probably why you don't get it. Think of it as a description of some geometry. What it creates when compiled is fixed and predetermined, so nothing needs to change value during compilation.

Going back to your original problem I use this pair of functions to pick fasteners and then base other dimensions on the length of those fasteners. E.g.

function screw_longer_than(x) = x <= 10 ? 10 :
                                x <= 12 ? 12 :
                                x <= 16 ? 16 :
                                ceil(x / 5) * 5;

function screw_shorter_than(x) = x > 20 ? floor(x / 5) * 5 :
                                 x > 16 ? 16 :
                                 x > 12 ? 12 :
                                 10;

frame_screw_length = frame_nuts ? screw_longer_than(
                                      sheet_thickness(frame)
                                      + part_base_thickness +
                                      (cnc_sheets ? 1 : 2) * washer_thickness(frame_washer)
                                      + nut_thickness(frame_nut, true)
                                  )

                                : screw_shorter_than(
                                      sheet_thickness(frame)
                                      + part_base_thickness
                                      + 2 * washer_thickness(frame_washer)
                                  );

It could be more elegant with a list of small screw sizes and recursive functions but with such a short list this is probably more readable.



On 18 September 2014 08:52, MichaelAtOz <[hidden email]> wrote:
Gaston Gloesener wrote
> Well this time the request comes from someone who has built a lot of
> compilers in his life and did teach compiler building at university in the
> past. You seem to describe the current behavior as a feature, while I do
> see it more like a bug.

I too have built compilers, not a lot, and a learnt a lot at university.
Many people here are very versed in language design etc. So you may wish to
give some of their responses some consideration.

> I really think that this is a design error at the start of the development
> due to lack of experience with compiler building at that time. This should
> not be seen as offense to the developer,

I'll let the designer speak for him self when he reads this. As I understand
it this is a specific design approach not a bug or design error. It just
reflects that you are still NOT getting the intent of this language.

> As by your writings I understand that the compiler is building an
> execution tree

 No it is building a static geometry tree, have a look at the
Design/Display... which shows them. They are not executed, the geometry is
evaluated.

>>> assignments (at least at top level) are internally handled in a
>>> separate list which take them out of sync with the other code.
>> Not sure what you are getting at??
>
> This is internal OpenSCAD stuff. When the parser encounters an assignment
> it will add it to a separate list of assignments. This does take the
> assignment out of the sequence of other code which makes the language
> sequentially incoherent. In a language (omitting control structures) if A
> is coded before B, A should be executed before B which is not the case in
> OpenSCAD due to the assignment list.

Again reflects you not getting the language. As Joseph said there is no
'Then' hence there is no 'before', there only 'is' and 'is not'.

>> Some other general points. (and yes it can be difficult, but you build up
>> a different programming mind set and it gets easier)
>
> With my background I have to disagree here. Every language has its "mind
> set" but also should follow general rules. I am regularly programming in
> many different languages adapting to those mindsets, and basically
> selecting the language upon it for the required task. Many languages base
> on the C/C++ mindset (like java, php,...) while others are more or less
> completely different (like python or lisp) but ALL of them follow the
> general rules.

Well, you will learn... Try thinking LISP with constants. Try thinking of
OpenSCAD 'variables' as constants.

> For sure I have (and know how) to handle it with the current bahavior for
> my current project, but would be great if this could be changed in a
> future release.

p.s. There are a number of OpenSCAD offshoots which have gone procedural,
you may want to check them out.



-----
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-tp9647p9658.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 ?

Gaston Gloesener
In reply to this post by kintel
>> Are there any plans to change this behavior and make variables behave like in other programming languages ?
> Yes, see https://github.com/openscad/openscad/issues/347
>  -Marius

My understanding of this is that it will allow assignment at any level but still the assigned variable scope will be local. So the following will not work:

...
A=1;
If(option) { A=2; }
Echo(A);  // Should output 2 if "option" is true

If so, would you be willing to implement global and super scope assignments inside the blocks wither by keyword (ex.: "super A=1;", "global A=1;") or prefix(ex. "^A=1;" , "@A=1") if I find a way doing so without requiring heavy code changes ? And I think I have one. I just have to make sure it is coherent and is compatible with the current code base. It will also allow A=A+1;

I do also have to be sure that I get the working of the compiler correctly:

- The compiler builds an assignment list at each scope level containing the name and assigned expression (not evaluated value) of the variable ?
- As a result the list only contains the last assignment at current scope at the start of the execution of the same scope
- The compiler builds an execution tree of the other code ?
- At execution time all variables are considered constant for the current scope ?
- This also include for loop variables for which the scope is generated for each loop ?
- Module and function calls (like sin) are stored in the tree with their arguments as expressions (non evaluated)

With this my solution will not generate a lot of code change (rather small change in the assignment part of the bison file and one or 2 non-complex additional functions for the execution time). No changes in the overall execution model

If interested I will drive further my work on this and document it once I have verified that it could work as expected and is compatible with current code. Of course even then it is up to you to decide whether it would be implemented. I did not have a long look at the code, and as said my thoughts are not complete yet, but at present I would estimate the required code to less than 50 lines, probably less than 20.

- Gaston

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Marius Kintel
Sent: Thursday, September 18, 2014 4:41 AM
To: [hidden email]
Subject: Re: [OpenSCAD] Plans to change variable behavior ?

On Sep 17, 2014, at 19:00 PM, Gaston Gloesener <[hidden email]> wrote:

> Are there any plans to change this behavior and make variables behave like in other programming languages ?

Yes, see https://github.com/openscad/openscad/issues/347
I haven’t had time to properly fix this, see e.g. https://github.com/openscad/openscad/blob/master/src/localscope.cc#L58, but it’s definitely on the radar.
Se also this proposal, which partially ties into this issue: https://github.com/openscad/openscad/wiki/OEP3%3A-Function-Values-and-Variable-Scoping-improvements

 -Marius


_______________________________________________
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 Gloesener
In reply to this post by Joseph Lenox

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Joseph Lenox
Sent: Thursday, September 18, 2014 9:45 AM
To: [hidden email]
Subject: Re: [OpenSCAD] Plans to change variable behavior ?

 

Joseph Lenox wrote:

OpenSCAD is not a programming language, it's a HDL similar in scope to VHDL or Verilog's structural mode. Treating it like a programming language (like C/C++/Java/Lisp/PHP/Python),

                IMHO, is a mistake.  It's NOT A PROGRAMMING LANGUAGE. for() in OpenSCAD works just like for...generate() in VHDL. Modules also work pretty much the same way.


Am I making sense here?

 

Indeed this makes sense, and you are right. But this does not impact my sayings as it is of no importance if one calls it “programming language” or something else. In gobal scope they all are descriptive languages of desired behavior, generating this behavior. I am not a VHDL expert but the difference between a programming language and VHDL lies in the execution model not the language model. They both follow the same general computer language rules.
 
I agree that the result of an OpenSCAD compilation is closer to a VHDL “program” than to a common programming language. But the resulting behavior at execution time is the same in VHDL than in a programming language, as opposite to OpenSCAD.
 
Not sure if I make sense this time ;-)
 
 
 
 

_______________________________________________
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 ?

Simon
I don't know if my two cents are useful here, I just repeatedly read (V)HDL vs programming language with their different paradigms.

I just want to tell that in VHDL you have to  see the difference between signals and variables. It's been a long time since I've written any VHDL, but as far as I remember, it's something like this:

Signal assignment is not at all comparable to assignment to variable assignment in C/C++/Java...

So:

A <= B;
B <= C;
C <=D;

means the very same as

A <= C;
A <= B;

which is: A is always the same as B which is always the same as C.

But on the other side, there are also variables in VHDL. But their scope is within processes. So, within a process, there is this "standard" assignment known by C/C++/... programmers.
A process itself is always executed in no time. So looking from the "outside" to a process, the execution ends just in the very same time when it started. This means that a process is "executed" a bit like a "normal" program, but then, the only thing that is taken to the outside of the process is: How does the output vector depend on the input vector. And here, we are concurrent again. If you then try to "change" this output again "afterwards", there is an error. Because there is no "afterwards" outside the process in the meaning of "later in the execution sequence" of a "normal" programming language.

Again, probably you all know that, too, I just wanted to stress, that also in a HDL, there are variables, but their scope is limited. They simply cannot be "global", because, that would mean that the hardware should change in time.

Greets
Simon


On 18.09.2014 10:56, Gaston Gloesener wrote:

 

 

From: [hidden email] [[hidden email]] On Behalf Of Joseph Lenox
Sent: Thursday, September 18, 2014 9:45 AM
To: [hidden email]
Subject: Re: [OpenSCAD] Plans to change variable behavior ?

 

Joseph Lenox wrote:

OpenSCAD is not a programming language, it's a HDL similar in scope to VHDL or Verilog's structural mode. Treating it like a programming language (like C/C++/Java/Lisp/PHP/Python),

                IMHO, is a mistake.  It's NOT A PROGRAMMING LANGUAGE. for() in OpenSCAD works just like for...generate() in VHDL. Modules also work pretty much the same way.


Am I making sense here?

 

Indeed this makes sense, and you are right. But this does not impact my sayings as it is of no importance if one calls it “programming language” or something else. In gobal scope they all are descriptive languages of desired behavior, generating this behavior. I am not a VHDL expert but the difference between a programming language and VHDL lies in the execution model not the language model. They both follow the same general computer language rules.
 
I agree that the result of an OpenSCAD compilation is closer to a VHDL “program” than to a common programming language. But the resulting behavior at execution time is the same in VHDL than in a programming language, as opposite to OpenSCAD.
 
Not sure if I make sense this time ;-)
 
 
 
 


_______________________________________________
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 ?

Simon
 oops, the example with the signal assignment is obviously wrong, I forgot the signal D. :-)

Maybe even more expressive is:

A<=B;
B<=C;

is the same as
B<=C
C<=A

By writing any of these, you "force" A to be the same as B and C. Like a solder joint of the three wires A, B and C being on 0V or 3.3V.

If you now say:

A<=0;
A<=1;


an you would compile this, you would get an error. Because 1 is not 0. It's simply impossible for A to be on 0V and on the same time on 3.3V (I'm not mentioning the states "H", "L",... here.

If there would be no error, the only thing a VHDL compiler could possibly do, is shorten the power line and the ground line. But this is not what we want. ;-)



On 18.09.2014 11:15, Simon Huwyler wrote:
I don't know if my two cents are useful here, I just repeatedly read (V)HDL vs programming language with their different paradigms.

I just want to tell that in VHDL you have to  see the difference between signals and variables. It's been a long time since I've written any VHDL, but as far as I remember, it's something like this:

Signal assignment is not at all comparable to assignment to variable assignment in C/C++/Java...

So:

A <= B;
B <= C;
C <=D;

means the very same as

A <= C;
A <= B;

which is: A is always the same as B which is always the same as C.

But on the other side, there are also variables in VHDL. But their scope is within processes. So, within a process, there is this "standard" assignment known by C/C++/... programmers.
A process itself is always executed in no time. So looking from the "outside" to a process, the execution ends just in the very same time when it started. This means that a process is "executed" a bit like a "normal" program, but then, the only thing that is taken to the outside of the process is: How does the output vector depend on the input vector. And here, we are concurrent again. If you then try to "change" this output again "afterwards", there is an error. Because there is no "afterwards" outside the process in the meaning of "later in the execution sequence" of a "normal" programming language.

Again, probably you all know that, too, I just wanted to stress, that also in a HDL, there are variables, but their scope is limited. They simply cannot be "global", because, that would mean that the hardware should change in time.

Greets
Simon


On 18.09.2014 10:56, Gaston Gloesener wrote:

 

 

From: [hidden email] [[hidden email]] On Behalf Of Joseph Lenox
Sent: Thursday, September 18, 2014 9:45 AM
To: [hidden email]
Subject: Re: [OpenSCAD] Plans to change variable behavior ?

 

Joseph Lenox wrote:

OpenSCAD is not a programming language, it's a HDL similar in scope to VHDL or Verilog's structural mode. Treating it like a programming language (like C/C++/Java/Lisp/PHP/Python),

                IMHO, is a mistake.  It's NOT A PROGRAMMING LANGUAGE. for() in OpenSCAD works just like for...generate() in VHDL. Modules also work pretty much the same way.


Am I making sense here?

 

Indeed this makes sense, and you are right. But this does not impact my sayings as it is of no importance if one calls it “programming language” or something else. In gobal scope they all are descriptive languages of desired behavior, generating this behavior. I am not a VHDL expert but the difference between a programming language and VHDL lies in the execution model not the language model. They both follow the same general computer language rules.
 
I agree that the result of an OpenSCAD compilation is closer to a VHDL “program” than to a common programming language. But the resulting behavior at execution time is the same in VHDL than in a programming language, as opposite to OpenSCAD.
 
Not sure if I make sense this time ;-)
 
 
 
 


_______________________________________________
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 ?

Gaston Gloesener
In reply to this post by MichaelAtOz
MichaelAtOz wrote:

> I too have built compilers, not a lot, and a learnt a lot at university.

Well at least you were not my studend as you would understand why I call it a design error, so far. ;-)

> As I understand it this is a specific design approach not a bug or design error. It just reflects that you are still NOT getting the intent of this language.

Let's not get personal here, please. Sequential integrity, keeping promises and implicit promises are basic language design rules, which are independent of the context. As with every topic rules can be broken but there need to be a good reason for it. So far beside telling me that  "I do NOT understand the language"  I did not come across such a reason. The rules violated by the OpenSCAD language are so basic that I have no knowledge of a single language in any context doing so, except some theoretical AI language design, but this is far beyond the topic here.

>> As by your writings I understand that the compiler is building an
>> execution tree
>  No it is building a static geometry tree, have a look at the Design/Display... which shows them. They are not executed, the geometry is evaluated.

This is not what I see in the code,, nor what my tests show. You are speaking of the final result not the execution phase. Any language interpretation/comoilation phase building an executtion model and an execution model.  Evaluation is a subset of an execution model BTW. In some languages interpretation and execution is interleaving but there is always an execution model. As far as I understood the code by my glance at it (what a UI displays is not really relevant) my explanation of the execution model fits.

>>> assignments (at least at top level) are internally handled in a
>>> separate list which take them out of sync with the other code.
>> Not sure what you are getting at??
>
> This is internal OpenSCAD stuff. When the parser encounters an
> assignment it will add it to a separate list of assignments. This does
> take the assignment out of the sequence of other code which makes the
> language sequentially incoherent. In a language (omitting control
> structures) if A is coded before B, A should be executed before B
> which is not the case in OpenSCAD due to the assignment list.

> Again reflects you not getting the language. As Joseph said there is no 'Then' hence there is no 'before', there only 'is' and 'is not'.

LOL, I simply explain how OpenSCAD works internally and general rules ANY language should follow.

What you are trying to explain me is like you having an accident at a crossing with a car caming across on the crossing road while you passed a red traffic light. While the police is trying to explain you that it was all your fault because you passed the red traffic light, you emphase that they have to understand they are wrong, and they have to understand that the accident actually only happened because there was a car on the crossing road. Sure if that car was not there, crossing the red light would have had no effect. But still, crossing the red light ist not correct.

But anyway this discussion dos not lead anywhere. I can't summarize here what my students are told during hours and hours.

> Well, you will learn... Try thinking LISP with constants. Try thinking of OpenSCAD 'variables' as constants.

OK, I'll stop it here. Your sayings here are not in anyway related to mine, LISP is not violating any of the rules I claim here. If you really have studied compiler building explicitely at university (as I said not as my student) you should really not have written the last sentence.

But anyway, thank you for your thoughts.


_______________________________________________
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
In reply to this post by Simon
>the resulting behavior at execution time is the same in VHDL than in a programming language

There is no "execution time" with VHDL. It describes some hardware which then gets synthesised and implemented in real logic or simulated. The generated hardware can do whatever you want. I can have registers that change value over time but that is not the same as saying VHDL has an execution time where variables take on different values.

On 18 September 2014 10:25, Simon Huwyler <[hidden email]> wrote:
 oops, the example with the signal assignment is obviously wrong, I forgot the signal D. :-)

Maybe even more expressive is:

A<=B;
B<=C;

is the same as
B<=C
C<=A

By writing any of these, you "force" A to be the same as B and C. Like a solder joint of the three wires A, B and C being on 0V or 3.3V.

If you now say:

A<=0;
A<=1;


an you would compile this, you would get an error. Because 1 is not 0. It's simply impossible for A to be on 0V and on the same time on 3.3V (I'm not mentioning the states "H", "L",... here.

If there would be no error, the only thing a VHDL compiler could possibly do, is shorten the power line and the ground line. But this is not what we want. ;-)




On 18.09.2014 11:15, Simon Huwyler wrote:
I don't know if my two cents are useful here, I just repeatedly read (V)HDL vs programming language with their different paradigms.

I just want to tell that in VHDL you have to  see the difference between signals and variables. It's been a long time since I've written any VHDL, but as far as I remember, it's something like this:

Signal assignment is not at all comparable to assignment to variable assignment in C/C++/Java...

So:

A <= B;
B <= C;
C <=D;

means the very same as

A <= C;
A <= B;

which is: A is always the same as B which is always the same as C.

But on the other side, there are also variables in VHDL. But their scope is within processes. So, within a process, there is this "standard" assignment known by C/C++/... programmers.
A process itself is always executed in no time. So looking from the "outside" to a process, the execution ends just in the very same time when it started. This means that a process is "executed" a bit like a "normal" program, but then, the only thing that is taken to the outside of the process is: How does the output vector depend on the input vector. And here, we are concurrent again. If you then try to "change" this output again "afterwards", there is an error. Because there is no "afterwards" outside the process in the meaning of "later in the execution sequence" of a "normal" programming language.

Again, probably you all know that, too, I just wanted to stress, that also in a HDL, there are variables, but their scope is limited. They simply cannot be "global", because, that would mean that the hardware should change in time.

Greets
Simon


On 18.09.2014 10:56, Gaston Gloesener wrote:

 

 

From: [hidden email] [[hidden email]] On Behalf Of Joseph Lenox
Sent: Thursday, September 18, 2014 9:45 AM
To: [hidden email]
Subject: Re: [OpenSCAD] Plans to change variable behavior ?

 

Joseph Lenox wrote:

OpenSCAD is not a programming language, it's a HDL similar in scope to VHDL or Verilog's structural mode. Treating it like a programming language (like C/C++/Java/Lisp/PHP/Python),

                IMHO, is a mistake.  It's NOT A PROGRAMMING LANGUAGE. for() in OpenSCAD works just like for...generate() in VHDL. Modules also work pretty much the same way.


Am I making sense here?

 

Indeed this makes sense, and you are right. But this does not impact my sayings as it is of no importance if one calls it “programming language” or something else. In gobal scope they all are descriptive languages of desired behavior, generating this behavior. I am not a VHDL expert but the difference between a programming language and VHDL lies in the execution model not the language model. They both follow the same general computer language rules.
 
I agree that the result of an OpenSCAD compilation is closer to a VHDL “program” than to a common programming language. But the resulting behavior at execution time is the same in VHDL than in a programming language, as opposite to OpenSCAD.
 
Not sure if I make sense this time ;-)
 
 
 
 


_______________________________________________
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


_______________________________________________
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 Gloesener
In reply to this post by Joseph Lenox

Joseph Lenox wrote:

 

And this is why VHDL doesn't have variables outside of behavioral mode. I think that the current design of OpenSCAD, which is similar to VHDL structural (or concurrent),

is generally correct for this domain.

You are right, its more like VHDL concurrent assignment, but not really. In VHDL you can create proper sequential assignments like in a CRC circuit using concurrent assignment to. Of course there is a reason of concurrent assignments in VHDL as this is a requirement of the behavioral target, I don’t see such requirement on OpenSCAD.

 


Additionally, any changes to how identifiers behave would need to be handled in a way that is at least marginally backwards-compatible.
I don't have a real problem with "variables" in this system, but I would prefer them to be constrained to an area that is always guaranteed to be procedurally generated (as you programmers expect), but aren't dependent on anything outside of the module (so existing behavior is maintained).

 

 
Ok, that is a constructive remark. Could you elaborate why variables should stick to their area (I understand this to mean “to be local”). But possibly reading the lines below will fit your thoughts already.
 
Maybe I should tell that beside the variable behavior the main goals of my suggestion are:
 
-          Simple to implement
-          100% compatible with existing code
 
This implies that
 
-          The general execution model is not changed at all. For most model files the generated tree should event be the same as before. The resulting geometry list will be the same of course.
-          Variables when assigned in a block scope (I,.e {}) will be local by default. Any assignment of a variable of a higher scope must be explicitly requested. 
-          The previous point can be error prone so that I am evaluating how to reduce/eliminate this
 
Thanks,
Gaston
 

_______________________________________________
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 Gloesener
In reply to this post by nophead

nop head wrote:

Ø  You don't mention any pure functional languages or purely declarative languages, which is probably why you don't get it. Think of it as a description of some geometry. What it creates when compiled is fixed and predetermined, so nothing needs to change value during compilation.

Well I speak of computer languages in general as I have analyzed, worked with and developed many languages over the time. These rules do not stick with a specific flavor of language.

Ø  Going back to your original problem I use this pair of functions to pick fasteners and then base other dimensions on the length of those fasteners. E.g.

Thanks for your suggestion. My problem is somewhat different. It is rendered complex by the fact that the design is quite complex and not developed in the mind of having these automatic adaptions. I did not say that I don’t know how to implement the required adaping code but the suggested changes would render them much more straight forward and thus less error prone.

 


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