Plans to change variable behavior ?

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

Re: Plans to change variable behavior ?

nophead
If you do that then calling a module can have side effects, which is very bad idea for code readability and correctness.

It also means that you can't rely on it always creating the same geometry from the same parameters, so it can't be cached and re-used as it is now. And you can run it in parallel, which is an obvious optimisation for a tree structure of geometry.

On 18 September 2014 11:05, Gaston Gloesener <[hidden email]> wrote:

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


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

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.


Not sure if useful neither, but interesting anyway J. As previously said I am no expert at all in VHDL, but my understanding is that these examples are concurrent assignments which depend on the signals received. Both codes are not the same in my eyes: A ==B==C only applies when signal D (then  A==B==C==D) or C is received, not if B is received. Also in the second (modified) example A will be the same as B or the same as C. the 3 values are only equal if B==C.

But I may be wrong here. Happy to extend my VHFL skills as they have plenty of room to do so :).

 


_______________________________________________
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
Those assignments mean that A,B, C and D all refer to the same signal, i.e. one piece of wire, so they always have the same value in the resulting circuit or a simulation, but they have no value during VHDL compilation.

On 18 September 2014 11:25, Gaston Gloesener <[hidden email]> wrote:

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.


Not sure if useful neither, but interesting anyway J. As previously said I am no expert at all in VHDL, but my understanding is that these examples are concurrent assignments which depend on the signals received. Both codes are not the same in my eyes: A ==B==C only applies when signal D (then  A==B==C==D) or C is received, not if B is received. Also in the second (modified) example A will be the same as B or the same as C. the 3 values are only equal if B==C.

But I may be wrong here. Happy to extend my VHFL skills as they have plenty of room to do so :).

 


_______________________________________________
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
Gaston Gloesener wrote
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.
"were not my student as you would understand " ... I understand perfectly, it seems, in the face of many others, patiently trying to guide to, you are yet to understand.
> 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.
I have read the OpenSCAD code backwards and forwards. It simply is not ANY language in the context you are sitting in.
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.
Yet again you use term like 'while' 'passed' 'happened' 'crossing'. These do not apply, it is not procedural, there is no before or after, which is why A = A +1 is meaningless.
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.
It was an attempt to get you thinking outside your box, not a technical description.
But anyway, thank you for your thoughts.
I will keep trying to hammer the nail, like the others here, it may get through...

I reiterate, there are OpenSCAD offshoots, which have gone down the procedural path, see related projects, they may be more suited to your mind set.
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 ?

Simon
In reply to this post by Gaston
I think, again, to be exact, you have to even differ between simulation and synthesis (which is more like what OpenSCAD does).

In simulation, to be exact (correct me if I'm wrong)

A<=B;
means that as soon as there is a change in B, A changes. Not at the very same time, but after the shortest time the simulation can handle (Sort of the simulation time quantum).

So, B changes at time x. This results in an entry into the event list at time x+(veeeeeeeeeeeeeery short time), that A changes. And so on.

BUT:
In synthesis, the synthesizer looks at the whole bunch of code and thinks: "What is this hardware supposed to do? Ah, I see. A must equal B, which must equal C. So.... Let's just solder these together."

This completely different approach is the reason why it's a huge difference between coding for simulation and coding for synthesis. Although the syntax is the same. For example. A Synthesizer won't ever accept an "after". So:

A<=B after 5ms is not acceptable. Because The synthesizer has no chance to find out how this is achieved in hardware.

For the simulator, it's easy. Put an entry into the event queue that sais: A goes to 1 at (now plus 5ms).

Bottom line:
I think, OpenSCAD is more like VHDL for synthesis, not for simulation.


On 18.09.2014 12:25, Gaston Gloesener wrote:

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.


Not sure if useful neither, but interesting anyway J. As previously said I am no expert at all in VHDL, but my understanding is that these examples are concurrent assignments which depend on the signals received. Both codes are not the same in my eyes: A ==B==C only applies when signal D (then  A==B==C==D) or C is received, not if B is received. Also in the second (modified) example A will be the same as B or the same as C. the 3 values are only equal if B==C.

But I may be wrong here. Happy to extend my VHFL skills as they have plenty of room to do so :).

 



_______________________________________________
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 MichaelAtOz
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.
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
Whenever you're ready, I can live with it for a bit, I just thought it was ready to go, awaiting a build.
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
OOps, wrong post, pls ignore...
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 ?

Simon
In reply to this post by MichaelAtOz
Let's look at what simulation would do with this (if it's not captured
as an error):

A, for some reason, A becomes 5.
This means that A will become 6 after a veeeeeeeeeery short time.
This means that A will become 7 after a veeeeeeeeeery short time.
This means.....

And a synthesizer would maybe put an adder and short the output to the
input. Resulting in a perfect race condition.




On 18.09.2014 13:02, MichaelAtOz 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.
>
>
>
> -----
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

Simon
One more:

So, for a signal assignment, A <= A+1 is meaningless. That's a fact.
Simply because it's a lie. ;-)

But now look at a process in VHDL. A process having A in the event queue.

_Within_ this process, you define the _variable_  x. This is assigned
the value of A. Then, we assign x=x+1. (or :=? Don't know the syntax
anymore). This makes perfect sense.
Then, we assign a signal B the value of x, which is 2, after the process
was executed.

So, the process does the same as the concurrent assignment
B=A+1. Which means: _Whenever_ A changes, B will change to A+1.

Maybe this is where we are talking "across each other"? Variables in a
HDL _do_ make sense. But they must not be mixed with concurrent assignments.

On 18.09.2014 13:09, Simon Huwyler wrote:

> Let's look at what simulation would do with this (if it's not captured
> as an error):
>
> A, for some reason, A becomes 5.
> This means that A will become 6 after a veeeeeeeeeery short time.
> This means that A will become 7 after a veeeeeeeeeery short time.
> This means.....
>
> And a synthesizer would maybe put an adder and short the output to the
> input. Resulting in a perfect race condition.
>
>
>
>
> On 18.09.2014 13:02, MichaelAtOz 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.
>>
>>
>>
>> -----
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

Simon
"A process having A in the event queue." shoud read: ... in the sensitivity list. Sorry

On 18.09.2014 13:36, Simon Huwyler wrote:

> One more:
>
> So, for a signal assignment, A <= A+1 is meaningless. That's a fact.
> Simply because it's a lie. ;-)
>
> But now look at a process in VHDL. A process having A in the event queue.
>
> _Within_ this process, you define the _variable_  x. This is assigned
> the value of A. Then, we assign x=x+1. (or :=? Don't know the syntax
> anymore). This makes perfect sense.
> Then, we assign a signal B the value of x, which is 2, after the process
> was executed.
>
> So, the process does the same as the concurrent assignment
> B=A+1. Which means: _Whenever_ A changes, B will change to A+1.
>
> Maybe this is where we are talking "across each other"? Variables in a
> HDL _do_ make sense. But they must not be mixed with concurrent assignments.
>
> On 18.09.2014 13:09, Simon Huwyler wrote:
>> Let's look at what simulation would do with this (if it's not captured
>> as an error):
>>
>> A, for some reason, A becomes 5.
>> This means that A will become 6 after a veeeeeeeeeery short time.
>> This means that A will become 7 after a veeeeeeeeeery short time.
>> This means.....
>>
>> And a synthesizer would maybe put an adder and short the output to the
>> input. Resulting in a perfect race condition.
>>
>>
>>
>>
>> On 18.09.2014 13:02, MichaelAtOz 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.
>>>
>>>
>>>
>>> -----
>>> 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 MichaelAtOz
Simon,
  The meaning of A <= B; outside of a process is that A is the same signal as B. They become the same net. There is never any time difference between them changing, even in a simulation. If it simulates direct from the VHDL and creates a small time delta then it just a deficiency in the simulator or an artefact of its implementation.

Inside a process it is different. If you say on a clock edge that A <= B; B <= C; then you effectively create a shift register, rather than a wire, and A B and C can have different values for each other.
 

On 18 September 2014 12:05, MichaelAtOz <[hidden email]> wrote:
OOps, wrong post, pls ignore...



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

Simon

On 18.09.2014 13:39, nop head wrote:
Simon,
  The meaning of A <= B; outside of a process is that A is the same signal as B. They become the same net.There is never any time difference between them changing, even in a simulation. If it simulates direct from the VHDL and creates a small time delta then it just a deficiency in the simulator or an artefact of its implementation.
As far as I remember, a very basic element of a VHDL simulator is the even list. And in each "iteration" the simulator just looks up the next event(s) and calculates the following event(s) out of it. And to avoid a race condition in the simulator itself, it just puts them one time delta (which is really veeeeeeeeeeeeeery short ;-) later I mean to remember modelsim really showing these delays (which were in the fraction of fs). But you're right, that's no principal thing.
Inside a process it is different. If you say on a clock edge that A <= B; B <= C; then you effectively create a shift register,

Whis is because this is then not a signal assignment, but a shift operator, of course. But I wouldn't call it "shift register", because _within_ the process, it's not hardware what you describe. Only the whole thing in the end, the process as a whole, is representing a piece of hardware.

rather than a wire, and A B and C can have different values for each other.

Yes. Again, because on this scope, it's _not_ actually hardware description, but "normal" sequential programming, resulting in a description of a piece of hardware.


But I think, we both have the same point under the bottom line.



 

On 18 September 2014 12:05, MichaelAtOz <[hidden email]> wrote:
OOps, wrong post, pls ignore...



-----
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-tp9647p9680.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566



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


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

Re: Plans to change variable behavior ?

nophead


On 18 September 2014 13:08, Simon Huwyler <[hidden email]> wrote:

On 18.09.2014 13:39, nop head wrote:
Simon,
  The meaning of A <= B; outside of a process is that A is the same signal as B. They become the same net.There is never any time difference between them changing, even in a simulation. If it simulates direct from the VHDL and creates a small time delta then it just a deficiency in the simulator or an artefact of its implementation.
As far as I remember, a very basic element of a VHDL simulator is the even list. And in each "iteration" the simulator just looks up the next event(s) and calculates the following event(s) out of it. And to avoid a race condition in the simulator itself, it just puts them one time delta (which is really veeeeeeeeeeeeeery short ;-) later I mean to remember modelsim really showing these delays (which were in the fraction of fs). But you're right, that's no principal thing.
Inside a process it is different. If you say on a clock edge that A <= B; B <= C; then you effectively create a shift register,

Whis is because this is then not a signal assignment, but a shift operator, of course. But I wouldn't call it "shift register", because _within_ the process, it's not hardware what you describe. Only the whole thing in the end, the process as a whole, is representing a piece of hardware.
 
No it isn't a shift operator. It is two assignments that only happen (in parallel) on a clock edge, so it implies a register. And the way the bits of the register are assigned to each other will form a short shift register.


rather than a wire, and A B and C can have different values for each other.

Yes. Again, because on this scope, it's _not_ actually hardware description, but "normal" sequential programming, resulting in a description of a piece of hardware.
 
No it isn't normal sequential code. Things happen on clock edges, all in parallel. Or, if you don't specify a clock then it happens continuously, all in parallel. If you did B<=C; A <= B; you would get exactly the same logic generated with the same behaviour. If you simulator gives a different result due to evaluating them sequentially it is wrong.
 


But I think, we both have the same point under the bottom line.



 

On 18 September 2014 12:05, MichaelAtOz <[hidden email]> wrote:
OOps, wrong post, pls ignore...



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

Gaston
In reply to this post by nophead

Nop head wrote:

 

Ø  If you do that then calling a module can have side effects, which is very bad idea for code readability and correctness.

I am not sure which part of my suggestion you are referring to, but it is true in regard of the global access to variables from a module. But this is a side-effect itself of global variables, and since access needs to be explicit I don’t see this as issue.

 

I give you an example (unrelated to the OpenSCAD language):

 

In the following syntax side effects are a real issue as the global a will remain 5, but if you foget the local statement it would be a=5; (unexpected side effect)

 

a=1;

module()

{

  local a;

 

a=5;

}

 

My current suggestion would be:

 

a=1;

module()

{

@a=5;

}

 

Also considered:

 

a=1;

module()

{

global a;

 

a=5;

}

 

The second suggestion is more restrictive. One could argue that both syntaxes (“local” and “global”) yell for the same problem but this is not the case. Of course forgetting one of them generates an effect for both (as well as for @) but diagnosing the global case should be much easier than the local one (still under investigation).

 

The important point is that the use of the new features will be explicit, i.e. any code written as by rtoday will not change in behavior.

 

 

 


> It also means that you can't rely on it always creating the same geometry from the same parameters, so it can't be cached and re-used as it is now. And you can run it in parallel, which is an obvious > optimisation for a tree structure of geometry.

 

Good point ! I will have to consider the caching point of view. At first thought a worst case would be that caching cannot be done (or only partially) when the code uses the feature. As the usage is explicit one may consider this ok. But I will try to get away of that worst case of course. Will have to analyze how caching works and how it is rendered dirty.

 

When it comes to different geometries with same parameters this is already possible today as there is a function for random numbers. On the other hand I don’t see how my feature suggestion would render different geometries at different runs with same parameters.

 

 


_______________________________________________
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
In reply to this post by nophead
Ok, there were several misunderstandings (on my side):


On 18.09.2014 14:33, nop head wrote:
No it isn't normal sequential code. Things happen on clock edges, all in parallel. Or, if you don't specify a clock then it happens continuously, all in parallel. If you did B<=C; A <= B; you would get exactly the same logic generated with the same behaviour. If you simulator gives a different result due to evaluating them sequentially it is wrong.
 

I thought of A and B as as vectors, and as variables.  Of course, as single signals, it's a 3-bit shift register.

What I meant in my example was  how _variables_ are treated within a process. And this is sequencial. It's perfectly fine to write

x:=x+1

within a process. before execution x is - say - 5. After it, it's 6. But the trick is, that the execution is infinitely fast. So as soon as the process is triggered (due to the sensitivity list), the evaluation begins and is finished at the same time. But the execution order is like in any "normal" language.

So, it's not as much about inside the process or outside of it, it's more about signal or variable. And as far as I understand, a global variable in openSCAD is more like a signal in VHDL.

If a cube is 10mm long, it cannot be 20mm long at the same time. And if the length is defined by a variable, it's clear that you cannot define this variable to be 10 and 20.


So, maybe (that's just a shot from the hip), openSCAD could also differ between 'variables' and 'signals' in the meaning of VHDL (though the name is stupid here).

But really, this is a shot from the hip! I just think, this may go a bit into the direction of what Gaston means...



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

Alan Cox
In reply to this post by Gaston
> 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.

Then you probably understand parallelism.

The huge potential win for not having sequential programming brokenness
in the behaviour of openscad is that once your backend can do it you can
evaluate all the subexpressions in parallel. In the case of OpenSCAD that
potentially means you can do most of the CSG geoemtry in parallel.

Processors are getting more parallel not faster.

If you do need to interface to something sequential (or pretend to in
order to make it work easily with a sequentially taught mind) then
openscad actually makes a rather convenient output target for tools. You
can simply take your own configuration as input and write a (quite
possibly horrid) openscad file as output.

I've built a whole collection of tools that do this in order to build
models from very specialised description languages and its working well
for me.

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

Re: Plans to change variable behavior ?

kintel
Administrator
In reply to this post by Gaston
This thread is getting too long. I’ll try to tie things together a bit:

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

As people have already hinted towards, we should take care of the following:
* Backwards compatibility
* Allow variable overrides on the cmd-line using the -D option
* Allow for caching of expensive geometry
* In terms of backwards compatibility and using the -D option, reassignment behavior appears to be the main issue

We’re also working on supporting:
* Parallel geometry evaluation: Traversing the node tree in parallel to build e.g. CSG geometry
* 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.
* 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.
* Context-aware evaluation: https://github.com/openscad/openscad/issues/149

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.

We’re also working on a V2 version of the language, where we’ll aim to clean up some of these issues. The challenge is that V1 code should be transparently upgradable to V2 code and it should be possible to use V1 libraries in V2 code. This needs significant work though, but I’m mentioning it in case it makes more sense to discuss your proposal in the context of such a language change.

On Sep 18, 2014, at 04:35 AM, Gaston Gloesener <[hidden email]> wrote:

> 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:
>
Your understanding is correct.

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

I’m a lot more concerned about my list above than I am about not wanting heavy code changes.

> I do also have to be sure that I get the working of the compiler correctly:
> […]

You’ve got it right; we create an AST which stores all modules, function, expressions and instantiations. This AST is evaluated into a node tree with only concrete geometry with concrete values (i.e. for loops are unrolled, module instantiations are replaced with their content etc.). The result of this can be exported into a so-called .csg file.

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

If you manage to not break any of the mentioned use-cases and maintain backwards compatibility, we’re indeed interested in including such changes.
It’s hard to get this right though, so I would strongly suggest doing green refactoring and introduce one small feature at a time.
The main issue seems to be assignment outside of the local scope - I would leave that to the very last as it’s likely to interfere quote a bit with the mentioned use-cases and future plans.

I hope this doesn’t demotivate you too much. You’ve stepped right into on of the weak points of OpenSCAD (weak as in we made some questionable decisions early on and we don’t want to break existing designs), so we have to thread lightly.

Cheers,

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

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Plans to change variable behavior ?

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.

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
12345