Nabble has removed Mailing-list integration.
Posts created here DO NOT GET SENT TO THE MAILING LIST.
Mailing-list emails DO NOT GET POSTED TO THE FORUM.
So basically the Forum is now out of date, we are looking into migrating the history.

For now you should send emails, people will see them, discuss@lists.openscad.org.

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 ?

jon_bondy
In Pascal, the notation is

a := a + 1

where ":=" is spoken as "gets".

The C notation has always annoyed me.  It has never been an equal sign.

Jon

On 9/18/2014 10:51 AM, nop head wrote:
A = A+1 makes no sense as a mathematical expression. It is only a construct invented by procedural programing languages. Pure functional languages don't allow it and it isn't necessary.

On 18 September 2014 15:47, Gaston Gloesener <[hidden email]> wrote:

> Basically, until you understand, and accept, why A=A+1 is meaningless, there is no point discussing this further. Think of it as a perceptual deficit.

Well there have been a number of valid and constructive remarks from others on this topic. Unfortunately yours are just getting personal  with no real content trying to tell me how dumb I am and that I have to understand that your view is the only truth.  But you are right in one thing, there is no point in discussing this with you any further.

You are just throwing in your view, with no explanation and you await that I accept it as a lamb.

like:

> Basically, until you understand, and accept, why A=A+1 is meaningless

Tell me why, and I will of course consider it. Also this is only a minor aspect of the feature and more a side effect of 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-tp9647p9678.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


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4765 / Virus Database: 4015/8233 - Release Date: 09/18/14



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

Lampbus
In reply to this post by nophead
I haven not read all the thread, (especially the more off topc stuff) but here is my bit trying to illuminate :

Whereas there may be a place for true variables, I believe that the problem the original poster is having is deeper.

We all love variables, they can be very useful. Mostly a variable can vary at 'run' time so that the program can alter it's behavor; do something different.
But Openscad does not generate a run time program.
It generates a lump of geometry.
It is not a compiler except to compile said geometry.

So anyone who claims that being a compiler expert has just disqualified themselves from this discussion....mostly.

It does not compile a program that is then run to respond to different input (perhaps it could, but that is a different thing entirely)

!

On 18/09/2014 15:51, nop head wrote:
A = A+1 makes no sense as a mathematical expression. It is only a construct invented by procedural programing languages. Pure functional languages don't allow it and it isn't necessary.

On 18 September 2014 15:47, Gaston Gloesener <[hidden email]> wrote:

> Basically, until you understand, and accept, why A=A+1 is meaningless, there is no point discussing this further. Think of it as a perceptual deficit.

Well there have been a number of valid and constructive remarks from others on this topic. Unfortunately yours are just getting personal  with no real content trying to tell me how dumb I am and that I have to understand that your view is the only truth.  But you are right in one thing, there is no point in discussing this with you any further.

You are just throwing in your view, with no explanation and you await that I accept it as a lamb.

like:

> Basically, until you understand, and accept, why A=A+1 is meaningless

Tell me why, and I will of course consider it. Also this is only a minor aspect of the feature and more a side effect of 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-tp9647p9678.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


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

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

That's actually a very useful insight! My background has a lot of HDL/FPGA work, so thinking about OpenSCAD like an HDL could really help me get things done. Thanks!

saar.


On Thu, Sep 18, 2014 at 8:45 AM, Joseph Lenox <[hidden email]> wrote:
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


_______________________________________________
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 reply to this post by kintel
Marius Kintel wrote:


        > Please review the following as this has been discussed at length earlier:
        > * https://github.com/openscad/openscad/issues/399
        > * https://github.com/openscad/openscad/issues/347
        > * http://forum.openscad.org/Variable-bug-td3523.html

Will do


        > As people have already hinted towards, we should take care of the following:
        > * Backwards compatibility

Absolutely, my goal is to remain 100% backward compatible. If this could not be achieved I agree that the feature could only be realized in a fork. But I am confident that the compatibility can be maintained.

        > * Allow variable overrides on the cmd-line using the -D option

Good point, I have to admit that I never considered the command line so far. Without having looked into the code now I would expect that th e-D assignments are just appended (physically through the parser, or virtually through direct update of the assignment list or overriding the actual required assignment, most probably the second latter as there is a requirement to initialize the variable).

The -D option would not be transparent to my feature suggestion  so it would require some code (few lines). I am confident  that this would be rather easy but the real deal depends on how the -D option is implemented. I will dig into that part as well coming up with a solution.

        > * Allow for caching of expensive geometry

Yes caching was one point I did initially overlook and I have not yet looked into that part. But I believe, from the general internal structure of openSCAD (don't forget I looked at the code today for the first time) that caching would not be an issue. Caching is most probably done from the CSG tree, i.,e. a cache entry would be a module with its parameters as identifier relating to the actual cached geometry. So if a module is called with the same parameters it will be taken out of the cache.

In this case the feature will have no impact as its scope finishes at the AST.

        > * In terms of backwards compatibility and using the -D option, reassignment behavior appears to be the main issue

As mentioned above I think that the -D issues can be avoided by a few code lines. When it comes to reassignment and backward compatibility I do fully agree with you, and this was already considered in my initial thoughts. I have currently two possible solutions for this:

1) Explicit enabling of the feature (like the option statement in VBA) with something like $reassign=true
2) a special keyword like "let var=expr;" where let appears to be already in use with the lists.
3) a special prefix like "@var=expr;"

I have discarded already solution 1 as it would make it difficult to extend existing code with the new feature as enabling the feature would change the behavior of the existing code.

        >We’re also working on supporting:
        > * Parallel geometry evaluation: Traversing the node tree in parallel to build e.g. CSG geometry

This will IMHO not be impacted by the feature as parallelism is likely to be only at CSG tree level not AST


        > * Lazy expression evaluation: Evaluate expressions at geometry creation time (what some people call “run-time”) to allow feedback from the geometry stage back into expressions. When combined with parallel geometry evaluation, this implies parallel traversal of also the AST.

OK, if the expressions move to the CSG tree then there is a potential issue with parallelism. Could you give me a brief example of how this is supposed to work and used once it would be implemented.

        > * Caching of expressions: Two evaluations of the same expression should yield the same result. This is important for e.g. animations where only parts of the object is changed per frame without having to evaluate the entire tree.

Tricky one :-) Will have to think about this one. Am I right assuming that caching of expressions is part of the process to move expressions to the CSG tree ? Caching at AST level would have similar issues or limited to the local scope because of the for variables, I would believe.

        > * Context-aware evaluation: https://github.com/openscad/openscad/issues/149

Will have a look

        > As you can see, these points interfere in varying degree with your proposal.
        > #149 is already being blocked by some of these issues. Solving this might solve a subset of what’s needed for your proposal.

Yep, working on it :-)

I am glad to see that you are open minded towards the suggestion, and I appreciate the time you took to list the issues you see in this context. Of course I will have to address all these issues for my final proposal without any major complexity increase for the feature to be realizable.

I will now read the articles your suggested and then work on the proposal itself.

Thank you for your support,
And BTW thank you to all the contributors of this great piece of software,

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 ?

kintel
Administrator
On Sep 18, 2014, at 11:41 AM, Gaston Gloesener <[hidden email]> wrote:
>
> Without having looked into the code now I would expect that th e-D assignments are just appended (physically through the parser […]

Yes, it’s appended as raw text to the read .scad source code. Somewhat of a hack, which we want to fix in V2.

> > * Lazy expression evaluation: Evaluate expressions at geometry creation time (what some people call “run-time”) to allow feedback from the geometry stage back into expressions. When combined with parallel geometry evaluation, this implies parallel traversal of also the AST.
>
> OK, if the expressions move to the CSG tree then there is a potential issue with parallelism. Could you give me a brief example of how this is supposed to work and used once it would be implemented.
>
This is on the early drawing board stage:
geom = import(“design.stl”);
translate(-geom.bounds().center) geom();

Also, function references:
path = function(t) [<some parametrized 3D path>];
sweep(path) circle();

> Tricky one :-) Will have to think about this one. Am I right assuming that caching of expressions is part of the process to move expressions to the CSG tree ? Caching at AST level would have similar issues or limited to the local scope because of the for variables, I would believe.
>
It’s not necessarily part of that process, but once expressions can return geometry, it will be more important. Right now, we could already benefit from caching expensive loops and recursions.

I still have a feeling that modifying variables out of scope is particularly tricky to add to OpenSCAD. We’ll have to see more proof of it actually working before commenting on whether it makes sense to add it.

Again, keep in mind that such features you propose can take a bit of time to get into the main codebase due to their potential for breaking existing designs. It’s always preferable to do green refactoring (which can be merged a lot quicker) and build features on top of that. In addition, that way, parts of your contributions can be accepted even if the features themselves for some reason won’t make it :)

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

 

Ø  A = A+1 makes no sense as a mathematical expression. It is only a construct invented by procedural programing languages. Pure functional languages don't allow it and it isn't necessary.

 

That is true. The 5ct question now is why does OpenSCAD has to be purely functional language. “pure functional” is not limited to languages but also extends to data sructures. Couldn’t OpenSCAD be an impure language having pure functional features weakened by my suggestion. Especially since the feature must be explicitly used. So by default the language remains pure functional (well from the theoretical point of view it is not a pure functional language anyway but it simulates the behavior of one).

 


_______________________________________________
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
Well you can probably write pure functional code in any language but languages that enforce it ensure code is more readable and less error prone.

I can't see why you need to mutate variables and worse still change out of scope ones in order to describe geometry, especially something like an electronics case. I can describe an entire 3D printer where all the plastic parts adjust themselves to fit the specified vitamins without ever wishing for such features.

On 18 September 2014 19:08, Gaston Gloesener <[hidden email]> wrote:

 

Ø  A = A+1 makes no sense as a mathematical expression. It is only a construct invented by procedural programing languages. Pure functional languages don't allow it and it isn't necessary.

 

That is true. The 5ct question now is why does OpenSCAD has to be purely functional language. “pure functional” is not limited to languages but also extends to data sructures. Couldn’t OpenSCAD be an impure language having pure functional features weakened by my suggestion. Especially since the feature must be explicitly used. So by default the language remains pure functional (well from the theoretical point of view it is not a pure functional language anyway but it simulates the behavior of one).

 


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

jon_bondy
Nop Head:

Are there specific tricks./techniques that you use to make your code so adaptable?  Would examples cool this discussion down?

Jon

On 9/18/2014 2:18 PM, nop head wrote:
Well you can probably write pure functional code in any language but languages that enforce it ensure code is more readable and less error prone.

I can't see why you need to mutate variables and worse still change out of scope ones in order to describe geometry, especially something like an electronics case. I can describe an entire 3D printer where all the plastic parts adjust themselves to fit the specified vitamins without ever wishing for such features.

On 18 September 2014 19:08, Gaston Gloesener <[hidden email]> wrote:

 

Ø  A = A+1 makes no sense as a mathematical expression. It is only a construct invented by procedural programing languages. Pure functional languages don't allow it and it isn't necessary.

 

That is true. The 5ct question now is why does OpenSCAD has to be purely functional language. “pure functional” is not limited to languages but also extends to data sructures. Couldn’t OpenSCAD be an impure language having pure functional features weakened by my suggestion. Especially since the feature must be explicitly used. So by default the language remains pure functional (well from the theoretical point of view it is not a pure functional language anyway but it simulates the behavior of one).



_______________________________________________
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 reply to this post by Lampbus

Richard Benjamin wrote:

 

 

Ø  I haven not read all the thread, (especially the more off topc stuff) but here is my bit trying to illuminate :

Whereas there may be a place for true variables, I believe that the problem the original poster is having is deeper.


Ø  We all love variables, they can be very useful. Mostly a variable can vary at 'run' time so that the program can alter it's behavor; do something different.

This is not a criteria identifying if a language is compiled or not. Compilation (can also be called translation)  is the process of translating a language to another language (be it machine code or other).

Ø  But Openscad does not generate a run time program.

This is not correct. The generated “language” in case of OpenSCAD is called AST  and is a tree representation of the program code. At that time there is no geometry involved. The fact that the language is not stored to a file is also not a criteria.

Ø    It generates a lump of geometry.

That is the second step, like executing a compile program, this is just done internally by OpenSCAD. Nevertheless the phases are there compilation than execution.

Ø   It is not a compiler except to compile said geometry.

Ø  So anyone who claims that being a compiler expert has just disqualified themselves from this discussion....mostly.

So you must be such an expert ;-)

 

 


It does not compile a program that is then run to respond to different input (perhaps it could, but that is a different thing entirely)

!

On 18/09/2014 15:51, nop head wrote:

A = A+1 makes no sense as a mathematical expression. It is only a construct invented by procedural programing languages. Pure functional languages don't allow it and it isn't necessary.

 

On 18 September 2014 15:47, Gaston Gloesener <[hidden email]> wrote:


> Basically, until you understand, and accept, why A=A+1 is meaningless, there is no point discussing this further. Think of it as a perceptual deficit.

Well there have been a number of valid and constructive remarks from others on this topic. Unfortunately yours are just getting personal  with no real content trying to tell me how dumb I am and that I have to understand that your view is the only truth.  But you are right in one thing, there is no point in discussing this with you any further.

You are just throwing in your view, with no explanation and you await that I accept it as a lamb.

like:

> Basically, until you understand, and accept, why A=A+1 is meaningless

Tell me why, and I will of course consider it. Also this is only a minor aspect of the feature and more a side effect of 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-tp9647p9678.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

 


_______________________________________________
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 jon_bondy
No not really. I just avoid hard coding numbers as far as possible and write in a pseudo object oriented style. So all my vitamins are described by a named list of attributes and have a module to draw them and functions to expose the attributes. I work upwards from those. So a plastic part will size itself to accommodate vitamins and again has functions to describe its size, etc, allowing it to be positioned correctly.

I also never define the same thing in two places. I always use a variable or a function to allow any expression to re-used rather than stated twice.

If anything needs to be calculated iteratively then I use recursive functions. For example I made a knife block from a list of knives. That used recursion as the position of each slot depends on the position of the knife to the left and the position of the row above plus the depth of the largest knife on the row, etc.

On 18 September 2014 19:21, jon <[hidden email]> wrote:
Nop Head:

Are there specific tricks./techniques that you use to make your code so adaptable?  Would examples cool this discussion down?

Jon


On 9/18/2014 2:18 PM, nop head wrote:
Well you can probably write pure functional code in any language but languages that enforce it ensure code is more readable and less error prone.

I can't see why you need to mutate variables and worse still change out of scope ones in order to describe geometry, especially something like an electronics case. I can describe an entire 3D printer where all the plastic parts adjust themselves to fit the specified vitamins without ever wishing for such features.

On 18 September 2014 19:08, Gaston Gloesener <[hidden email]> wrote:

 

Ø  A = A+1 makes no sense as a mathematical expression. It is only a construct invented by procedural programing languages. Pure functional languages don't allow it and it isn't necessary.

 

That is true. The 5ct question now is why does OpenSCAD has to be purely functional language. “pure functional” is not limited to languages but also extends to data sructures. Couldn’t OpenSCAD be an impure language having pure functional features weakened by my suggestion. Especially since the feature must be explicitly used. So by default the language remains pure functional (well from the theoretical point of view it is not a pure functional language anyway but it simulates the behavior of one).



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

Oskar
In reply to this post by Gaston
Gaston Gloesener wrote
"Richard Benjamin wrote
Ø  But Openscad does not generate a run time program.
This is not correct. The generated “language” in case of OpenSCAD is called AST  and is a tree representation of the program code. At that time there is no geometry involved. The fact that the language is not stored to a file is also not a criteria.
"Richard Benjamin wrote
Ø    It generates a lump of geometry.
That is the second step, like executing a compile program, this is just done internally by OpenSCAD. Nevertheless the phases are there compilation than execution.
The traditional definition of a program is an ordered sequence of operations to be executed by a machine. The AST in OpenSCAD is different in that it doesn't define any specific order of evaluation other than what follows from sequential and recursive definitions. You can pick any node in the tree, and its value can be evaluated with no more context than what is available by evaluating the direct parent nodes. This is a *very* powerful concept that makes the evaluation trivially parallelizable and memoizable.

Introducing a means–as you suggest–for nodes to modify the values of their parents brings with it so many problems of such magnitudes that entire research fields have had to be created for their study.

In perspective of that, it it astonishing really how little I find I miss mutable variables in OpenSCAD. One of the primary reasons is probably as Michael said that the code we write describe just a static state of geometry. No was or becomes, just is. I.e., there is no ongoing process being output, and no flow of time. No start and no end.

What you are asking for is nothing new (we get posts like yours every few weeks). Many have made good arguments, and I'm sure most all of us felt the lack of mutable variables limiting at first. But you soon adapt (it's really not that limiting) and find that by doing so the resulting code becomes clearer, more maintainable and less prone to errors.

Best,

Oskar
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

MichaelAtOz
Administrator
Wow, 51 posts, no quite the record.
I found last time we did this, OpenSCAD 3000, 147 posts...
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 ?

Gaston
In reply to this post by nophead

 

Nop head wrote:

Ø  languages that enforce it ensure code is more readable and less error prone.

Both statements are no features of pure functional languages. When it comes to readability, it is often seen as an easy topic, and well as often in life, it isn’t. Reading code is a multi level process which is similar to reading a book. In this process the lower levels (symbol and syntax recognition) are easier in IPL than PFPL for most humans. When it comes to higher level reading of the code it is not true that FPL is easier readable either, while it can be in some cases (and those are usually taken as example) it is worse than PFPL in others. But than again the main point is that this is not a feature of PFPL but depends largely on the FPL implementation (eg. The language itself), which applies to IPL likewise.

 

Also is PFPL not per se less error prone. It’s aim is to eliminate side effects which reduces (eliminates) the error sin this area, but this does not exclude other error sources to get more potential.

 

NOTE: OpenSCAD language is not PFPL from the language perspective

 

Ø  I can't see why you need to mutate variables

The need is not  mandatory in the sense it can’t be done otherwise, but as I said, for better readability (I’ll come to that).

 

Ø  and worse still change out of scope ones in order to describe geometry,

 

You have to distinguish between scope and function/module. While I agree that m initial thought was to include every scope breaking (e.g.. also globals from inside modules), do not know if I ever wrote that here, I could rethink about the module part. But (re-)assignment outside of scope is required by the feature.

 

Ø  especially something like an electronics case. I can describe an entire 3D printer where all the plastic parts adjust themselves to fit the specified vitamins without ever wishing for such features.

 

As I said, I did not state that it can’t be done.

 

Now let me take an example and try not arguing “that could be done that way in OpenSCAD”, I know that it all can be done, and the example ist chose explicitely without complexity just showing the feature not the application:

 

Flexible OpenSCAD programs have a first section defining the parameter section where a user can adapt variables for his needs. Let take part of my case where one can specify the inside feets on which the PCB ist to be scrwed:

 

pcb_foot_height=5;

pcb_thickness=1.6;

screw_length=16;

case_thickness=2;

 

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;

 

IMO the first reduces readability because a second variable needs to be introduced for the exact same purpose. While one can argument that reassignment now may have a side effect, th eimmutuable version has a bigger one IMHO.

 

In the second case (mutuable) the side effect comes from the fact that the variable can be changed and does not have the configured value. In the particular case of OpenSCAD (and we should not forget that I am not teaching language theory here, but we speak of application of one), the side effect would only play if the variable was misused.

 

In the first (immutuable) case now we have 2 variables having the exact same meaning, but pcb_foot_height is basically a wrong value.  From the user perspective having configured the pcb_foot_height but desiring to change the design of the feature he will look for this variable in the code but will find that it is not actually used in the module generating the foot at all, instead pcb_foot_h which can be confusing. As said above, not arguing about that is easy to resolve. In this example yes, but not if multiple variables with dependencies between them need to  be jumped through to understand which variable actually means what.

 

This said I maintain my statement that variables should be mutuable in OpenSCAD, but nevertheless I take this as  input to review the feature and analyzing if it requires further limitation to my initial thoughts.

 

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;

 

But this is exactly what is required due to the scope restriction in openSCAD today.

 

I hope this makes sense and shows the overall (much bigger) idea as I do not want to stretch this email any further with details.

 

Here again scope is different from function/module. I will also analyze this point against the different aspects of language design and use and possible (probably ?) revert from the thought of allowing to override the module scope.

 

 

 

 

 


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

clothbot

On Sep 19, 2014, at 5:34 AM, Gaston Gloesener <[hidden email]> wrote:
[deletia]
Now let me take an example and try not arguing “that could be done that way in OpenSCAD”, I know that it all can be done, and the example ist chose explicitely without complexity just showing the feature not the application:
 
Flexible OpenSCAD programs have a first section defining the parameter section where a user can adapt variables for his needs. Let take part of my case where one can specify the inside feets on which the PCB ist to be scrwed:
 
pcb_foot_height=5;
pcb_thickness=1.6;
screw_length=16;
case_thickness=2;
 
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;
 
IMO the first reduces readability because a second variable needs to be introduced for the exact same purpose. While one can argument that reassignment now may have a side effect, th eimmutuable version has a bigger one IMHO.


As it relates to designing something that can be fabricated/assembled, I disagree about the readability.  If the intent is that pcb_foot_height is a minimum height that can be overridden by screw length selection, I would rename the initial "pcb_foot_height" variable to something like "pcb_foot_height_min=5;".  Now I can detect the (screw_length>pcb_foot_height_min) condition at all times:

--snip--

pcb_foot_height_min=5;
pcb_thickness=1.6;
pcb_screw_length=16; // There's rarely more than one screw length :-)
case_thickness=2;

pcb_foot_height=(pcb_screw_length>pcb_foot_height_min)  ? pcb_screw_length : pcb_foot_height_min;

// I have now decided I don't want my pcb_foot_height overridden; detect the error.
if(pcb_foot_height>pcb_foot_height_min) {
echo(str("ERROR: pcb_foot_height (",pcb_foot_height,") > pcb_foot_height_min (",pcb_foot_height_min,")"));
} else {
pcb_frame();
}


It's more like the synthesizable subset of Verilog (the HDL I'm most familiar with) in this respect.

Andrew.

--

"The future is already here.  It's just not very evenly distributed" -- William Gibson

Me: http://clothbot.com/wiki/




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


On 19 September 2014 10:34, Gaston Gloesener <[hidden email]> wrote:

 

Nop head wrote:

Ø  languages that enforce it ensure code is more readable and less error prone.

Both statements are no features of pure functional languages. When it comes to readability, it is often seen as an easy topic, and well as often in life, it isn’t. Reading code is a multi level process which is similar to reading a book. In this process the lower levels (symbol and syntax recognition) are easier in IPL than PFPL for most humans. When it comes to higher level reading of the code it is not true that FPL is easier readable either, while it can be in some cases (and those are usually taken as example) it is worse than PFPL in others. But than again the main point is that this is not a feature of PFPL but depends largely on the FPL implementation (eg. The language itself), which applies to IPL likewise.

 

Also is PFPL not per se less error prone. It’s aim is to eliminate side effects which reduces (eliminates) the error sin this area, but this does not exclude other error sources to get more potential.


 

NOTE: OpenSCAD language is not PFPL from the language perspective

 

Ø  I can't see why you need to mutate variables

The need is not  mandatory in the sense it can’t be done otherwise, but as I said, for better readability (I’ll come to that).

 

Ø  and worse still change out of scope ones in order to describe geometry,

 

You have to distinguish between scope and function/module. While I agree that m initial thought was to include every scope breaking (e.g.. also globals from inside modules), do not know if I ever wrote that here, I could rethink about the module part. But (re-)assignment outside of scope is required by the feature.

 

Ø  especially something like an electronics case. I can describe an entire 3D printer where all the plastic parts adjust themselves to fit the specified vitamins without ever wishing for such features.

 

As I said, I did not state that it can’t be done.


Yes but I am arguing that not only can it be done but it is easy and more readable and more likely to be correct and there not advantages to mutable variables in a description, only downsides.

We are basically describing geometry with algebraic expressions and there is no reason why all the expressions cannot be pure and referentially transparent.
 

 

Now let me take an example and try not arguing “that could be done that way in OpenSCAD”, I know that it all can be done, and the example ist chose explicitely without complexity just showing the feature not the application:

 

Flexible OpenSCAD programs have a first section defining the parameter section where a user can adapt variables for his needs. Let take part of my case where one can specify the inside feets on which the PCB ist to be scrwed:

 

pcb_foot_height=5;

pcb_thickness=1.6;

screw_length=16;

case_thickness=2;

 

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;

 

IMO the first reduces readability because a second variable needs to be introduced for the exact same purpose. While one can argument that reassignment now may have a side effect, th eimmutuable version has a bigger one IMHO.


No that is exactly the mistake you and many people make and what immutable variables prevent. You now have  pcb_foot_height meaning two different things in different places. When looking at a use in the source code you have to spot that it has been changed, otherwise you would naturally assume it was the value you had set at the top. There are two related values that are different, so there should be two names. E.g.

target_pcb_foot_height = 5;

pcb_foot_height = screw_length > target_pcb_foot_height ? screw_length : target_pcb_foot_height;

This is far more readable and explicit because it immediately informs the user that what they set for the foot height is not necessarily what they get and any use of pcb_foot_height in the code always means the same thing.

Note you don't need the brackets if you know your operator precedence rules.

 

In the second case (mutuable) the side effect comes from the fact that the variable can be changed and does not have the configured value. In the particular case of OpenSCAD (and we should not forget that I am not teaching language theory here, but we speak of application of one), the side effect would only play if the variable was misused.

 

 
As soon as you allow a variable to have different meanings in different parts of the code you open up the possibility that it will be used while in the wrong state, or it will be changed causing subsequent uses to get the wrong value.
 

In the first (immutuable) case now we have 2 variables having the exact same meaning, but pcb_foot_height is basically a wrong value.  From the user perspective having configured the pcb_foot_height but desiring to change the design of the feature he will look for this variable in the code but will find that it is not actually used in the module generating the foot at all, instead pcb_foot_h which can be confusing. As said above, not arguing about that is easy to resolve. In this example yes, but not if multiple variables with dependencies between them need to  be jumped through to understand which variable actually means what.


This is only because you chose deficient names. With my naming scheme the exact same code is totally self explanatory. The user sets the target so has some expectation the actually value will be different. If he or she searches for the use of the target_pcb_foot_height he finds it is only used once to set the actual value and if he looks at uses of that name he knows they all yield the same value.

 

This said I maintain my statement that variables should be mutuable in OpenSCAD, but nevertheless I take this as  input to review the feature and analyzing if it requires further limitation to my initial thoughts.

 

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;

 

But this is exactly what is required due to the scope restriction in openSCAD today.

 

I hope this makes sense and shows the overall (much bigger) idea as I do not want to stretch this email any further with details.


If the condition is complex then you assign it to a variable, or a function, with a meaningful name. If by action you mean assign variables then the code is just as readable but slightly more verbose than your alternative but it has the big advantage that a variable must always be assigned a value. There are no spaghetti code paths that can skip setting it. A common mistake with nested if then else blocks.

 

Here again scope is different from function/module. I will also analyze this point against the different aspects of language design and use and possible (probably ?) revert from the thought of allowing to override the module scope.

 

 

 

 

 


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

G. Wade Johnson
In reply to this post by Gaston
On Fri, 19 Sep 2014 11:34:55 +0200
"Gaston Gloesener" <[hidden email]> wrote:

[snip]


> IMO the first reduces readability because a second variable needs to
> be introduced for the exact same purpose. While one can argument that
> reassignment now may have a side effect, th eimmutuable version has a
> bigger one IMHO.
>
>  
>
> In the second case (mutuable) the side effect comes from the fact
> that the variable can be changed and does not have the configured
> value. In the particular case of OpenSCAD (and we should not forget
> that I am not teaching language theory here, but we speak of
> application of one), the side effect would only play if the variable
> was misused.

I'd just like to comment on this one point. Not all of the people using
OpenSCAD are programmers. In my experience teaching non-programmers and
entry-level programmers, assignment turns out to be a difficult concept.

As was mentioned earlier in the thread, "A=A+1" is nonsensical from a
mathematical viewpoint. It is baffling to some non-programmers.

Having a name mean different things in different parts of the file is
one more thing these people need to overcome.

Personally, I was willing to deal with OpenSCAD variables being what I
would call constants in order to make things slightly easier for
designers without a programming background.

G. Wade
--
The computer should be doing the hard work. That's what it's paid to do,
after all.                                            -- Larry Wall
_______________________________________________
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
On Sep 19, 2014, at 05:34 AM, Gaston Gloesener <[hidden email]> wrote:

> 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;

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.

One alternative way of thinking about (re-)assignment is to open a new scope for every assignment, effectively making an assignment equivalent to assign(var=value) {<rest of block>}. This will still break existing behavior, so consider this food for the next OpenSCAD 3000 discussion :)

 -Marius

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

Re: Plans to change variable behavior ?

tp3
kintel wrote
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.
Would it be possible to:
* Disallow the reassignments completely
* Still allow -D to append code but if used to reassign something, give an error too
* Add -C to inject constant value assignments but not arbitrary code; Add those constants to the evaluation context
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

MichaelAtOz
Administrator
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...
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 ?

MichaelAtOz
Administrator
> Personally, I was willing to deal with OpenSCAD variables being what I
> would call constants in order to make things slightly easier for
> designers without a programming background.

While I agree re easier for non programmers; actually from my programmers (ingrained) background, it was coming to grips with variables, as actually sequential constants, was what slowed my learning. Once I made the breakthrough; as you say beginners - without a programming background clouding their thoughts - see this differently; makes the non procedural basis crystal clear.

Once you grok the declarative nature, it get so much easier.
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.
12345