Re: OpenSCAD Digest, Vol 58, Issue 33

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

Re: OpenSCAD Digest, Vol 58, Issue 33

laird
Wanting to use if/then/else to assign values has _nothing_ to do with procedural vs. functional programming.

The issue is that in OpenSCAD it's currently very hard to write an n-way branch expression, that evaluates to one of many options like a switch or stack of if/then/else, because the only such function in OpenSCAD right now is ?:, so you are forced to nest them in a way that's obscure and fragile.

A pretty normal way to express an n-way branch is with if/elseif/else.

if (cond1) value_1
elseif (cond2) value_2
...
else value_n;

Ignore that it looks like procedural code, and just think if it as a function, and we're good.

Where the expression evaluates to the first value associated with a condition that evaluates to true, or to the 'else' value if all conditions are false. The value can be a simple value, or geometry. And it already works to evaluate to geometry, so the 'feature request' would just be to extend it to work in functions to return a value.

That is, instead of a dense, obscure expression:

scale = isRaptor? EHscale : ((palmSelect==1)||(palmSelect==4)? CBscale : CCBscale);

I could write a much more clear:

scale = if isRaptor EHscale
elseif (palmSelect==1)||(palmSelect==4) CBscale
else CCBscale;

This would be useful both for modules and even more for functions. It's a construct in every functional language I've used, though the spelling varies.


On Thu, Sep 18, 2014 at 11:41 AM, <[hidden email]> wrote:
Send OpenSCAD mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://rocklinux.net/mailman/listinfo/openscad
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenSCAD digest..."


Today's Topics:

   1. Re: Plans to change variable behavior ? (Richard Benjamin)
   2. Re: Plans to change variable behavior ? (saar drimer)
   3. Re: Plans to change variable behavior ? (Gaston Gloesener)


----------------------------------------------------------------------

Message: 1
Date: Thu, 18 Sep 2014 16:10:05 +0100
From: Richard Benjamin <[hidden email]>
Subject: Re: [OpenSCAD] Plans to change variable behavior ?
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

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]
> <mailto:[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] <mailto:[hidden email]>
>     http://rocklinux.net/mailman/listinfo/openscad
>     http://openscad.org - https://flattr.com/thing/121566
>
>     _______________________________________________
>     OpenSCAD mailing list
>     [hidden email] <mailto:[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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rocklinux.net/pipermail/openscad/attachments/20140918/e3c15204/attachment-0001.html

------------------------------

Message: 2
Date: Thu, 18 Sep 2014 16:12:36 +0100
From: saar drimer <[hidden email]>
Subject: Re: [OpenSCAD] Plans to change variable behavior ?
To: [hidden email]
Message-ID:
        <CAEhErooBVoMOZTQvoo8pXz4xwT40fW-vYMEV98-Ncbb9k+d=[hidden email]>
Content-Type: text/plain; charset="utf-8"

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rocklinux.net/pipermail/openscad/attachments/20140918/b481694b/attachment-0001.html

------------------------------

Message: 3
Date: Thu, 18 Sep 2014 17:41:30 +0200
From: "Gaston Gloesener" <[hidden email]>
Subject: Re: [OpenSCAD] Plans to change variable behavior ?
To: <[hidden email]>
Message-ID: <012201cfd357$05430ed0$0fc92c70$@web.de>
Content-Type: text/plain;       charset="utf-8"

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


End of OpenSCAD Digest, Vol 58, Issue 33
****************************************


_______________________________________________
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: OpenSCAD Digest, Vol 58, Issue 33

nophead
scale = isRaptor ? EHscale
: (palmSelect==1)||(palmSelect==4) ? CBscale
: CCBscale;

scale = if isRaptor EHscale
elseif (palmSelect==1)||(palmSelect==4) CBscale
else CCBscale;

They look pretty much the same to me.

On 18 September 2014 19:22, Laird Popkin <[hidden email]> wrote:
Wanting to use if/then/else to assign values has _nothing_ to do with procedural vs. functional programming.

The issue is that in OpenSCAD it's currently very hard to write an n-way branch expression, that evaluates to one of many options like a switch or stack of if/then/else, because the only such function in OpenSCAD right now is ?:, so you are forced to nest them in a way that's obscure and fragile.

A pretty normal way to express an n-way branch is with if/elseif/else.

if (cond1) value_1
elseif (cond2) value_2
...
else value_n;

Ignore that it looks like procedural code, and just think if it as a function, and we're good.

Where the expression evaluates to the first value associated with a condition that evaluates to true, or to the 'else' value if all conditions are false. The value can be a simple value, or geometry. And it already works to evaluate to geometry, so the 'feature request' would just be to extend it to work in functions to return a value.

That is, instead of a dense, obscure expression:

scale = isRaptor? EHscale : ((palmSelect==1)||(palmSelect==4)? CBscale : CCBscale);

I could write a much more clear:

scale = if isRaptor EHscale
elseif (palmSelect==1)||(palmSelect==4) CBscale
else CCBscale;

This would be useful both for modules and even more for functions. It's a construct in every functional language I've used, though the spelling varies.


On Thu, Sep 18, 2014 at 11:41 AM, <[hidden email]> wrote:
Send OpenSCAD mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://rocklinux.net/mailman/listinfo/openscad
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenSCAD digest..."


Today's Topics:

   1. Re: Plans to change variable behavior ? (Richard Benjamin)
   2. Re: Plans to change variable behavior ? (saar drimer)
   3. Re: Plans to change variable behavior ? (Gaston Gloesener)


----------------------------------------------------------------------

Message: 1
Date: Thu, 18 Sep 2014 16:10:05 +0100
From: Richard Benjamin <[hidden email]>
Subject: Re: [OpenSCAD] Plans to change variable behavior ?
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

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]
> <mailto:[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] <mailto:[hidden email]>
>     http://rocklinux.net/mailman/listinfo/openscad
>     http://openscad.org - https://flattr.com/thing/121566
>
>     _______________________________________________
>     OpenSCAD mailing list
>     [hidden email] <mailto:[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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rocklinux.net/pipermail/openscad/attachments/20140918/e3c15204/attachment-0001.html

------------------------------

Message: 2
Date: Thu, 18 Sep 2014 16:12:36 +0100
From: saar drimer <[hidden email]>
Subject: Re: [OpenSCAD] Plans to change variable behavior ?
To: [hidden email]
Message-ID:
        <CAEhErooBVoMOZTQvoo8pXz4xwT40fW-vYMEV98-Ncbb9k+d=[hidden email]>
Content-Type: text/plain; charset="utf-8"

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rocklinux.net/pipermail/openscad/attachments/20140918/b481694b/attachment-0001.html

------------------------------

Message: 3
Date: Thu, 18 Sep 2014 17:41:30 +0200
From: "Gaston Gloesener" <[hidden email]>
Subject: Re: [OpenSCAD] Plans to change variable behavior ?
To: <[hidden email]>
Message-ID: <012201cfd357$05430ed0$0fc92c70$@web.de>
Content-Type: text/plain;       charset="utf-8"

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


End of OpenSCAD Digest, Vol 58, Issue 33
****************************************


_______________________________________________
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: OpenSCAD Digest, Vol 58, Issue 33

Alan Cox
In reply to this post by laird
> The issue is that in OpenSCAD it's currently very hard to write an n-way
> branch expression, that evaluates to one of many options like a switch or
> stack of if/then/else, because the only such function in OpenSCAD right now
> is ?:, so you are forced to nest them in a way that's obscure and fragile.
>

A map() operator would indeed be useful.

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: OpenSCAD Digest, Vol 58, Issue 33

MichaelAtOz
Administrator
In reply to this post by laird

isRaptor=false;
palmSelect=0;
EHscale=1;
CBscale=2;
CCBscale=3;

ELSE=true;

pairs =
  [ (isRaptor), (EHscale)
  , (palmSelect==1 || palmSelect==4), (CBscale)
  , (ELSE), (CCBscale)
  ];
       
function IFELSE( brp ) = // brp = boolean-result-pair vector
  (len(brp) < 1)
    ? undef
    : (len(brp) == 1)
      ? brp[0] // assume an else shortcut
      : (brp[0])
        ? brp[1]
        : IFELSE(
            [ for (i = [ 2: len(brp)-1]) brp[i] ] );
                 
r=IFELSE(pairs);
echo(r);
       
q = IFELSE([ (false), (1)
           , (false), ("b")
           , (ELSE),  ([1,2,3])
          ]);
echo(q);  
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

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

Re: OpenSCAD Digest, Vol 58, Issue 33

laird
In reply to this post by nophead
nophead,

Thanks, writing ?: like that looks odd, since it's not normally written that way, but you're right, broken onto multiple lines it's much easier to see the flow. Thanks. This is a useful enough technique that it should perhaps be added as an example on the ?: operator on the doc wiki page? Who owns those pages?

Perhaps adding the example:
---
// Example 'chaining' ?: operators returns the value for the first condition that is true

t1 = false;
t2 = true;
t3 = true;

x = t1 ? 1 // if t1 is true, return 1
: t2 : 2 // else if t2 is true, return 2
: 3; // else return 3

echo(x);
---
which prints "ECHO: 2" pretty much covers everything.

Come to think of it though, it does feel a little odd that you use ?: for "values" and you use if/then/else for geometry. Wouldn't it be better for them to be the same language structure?
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD Digest, Vol 58, Issue 33

nophead
Well OpenScad borrows its syntax from C and that is how C does it, which is handy if you are a C programmer as you don't have to learn anything new, including the fact it has the lowest precedence of all operators.

Python does:
value = x if c else y

Which is a different order and perhaps more natural.

On 21 September 2014 00:04, laird <[hidden email]> wrote:
nophead,

Thanks, writing ?: like that looks odd, since it's not normally written that
way, but you're right, broken onto multiple lines it's much easier to see
the flow. Thanks. This is a useful enough technique that it should perhaps
be added as an example on the ?: operator on the doc wiki page? Who owns
those pages?

Perhaps adding the example:
---
// Example 'chaining' ?: operators returns the value for the first condition
that is true

t1 = false;
t2 = true;
t3 = true;

x = t1 ? 1 // if t1 is true, return 1
: t2 : 2 // else if t2 is true, return 2
: 3; // else return 3

echo(x);
---
which prints "ECHO: 2" pretty much covers everything.

Come to think of it though, it does feel a little odd that you use ?: for
"values" and you use if/then/else for geometry. Wouldn't it be better for
them to be the same language structure?



--
View this message in context: http://forum.openscad.org/Re-OpenSCAD-Digest-Vol-58-Issue-33-tp9702p9742.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]


_______________________________________________
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: OpenSCAD Digest, Vol 58, Issue 33

laird
Perhaps it's just me, but using words feels more natural on multi-line expressions, and the ?: feels more natural packed into a one-liner (e.g. a small function).

Would it be too evil to ask that OpenSCAD support both phrasings? Not strictly necessary, of course, but while ?: is more compact, the Python phrasing is more readable.
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD Digest, Vol 58, Issue 33

nophead
Whilst I would have preferred Python syntax throughout I can think of several arguments against changing it now:

It would be odd to have two syntaxes for exactly the same thing. It means anybody learning OpenScad to be able to read it needs to learn both and having two would naturally lead people to thinking they were different in some way.

It would be odd to have to say the expression syntax is the same as C plus a little bit of Python, although the new list comprehension stuff is definitely not C, but I don't think it is the same as  Python either.

There is no distinction between single line or multi-line expressions or statements as white-space is not significant in either but there is a clear distinction between geometry creating statements and value yielding expressions so it is good to re-enforce that in the syntax.

Probably the biggest mistake in OpenScad is to use C statement syntax for making the tree of geometry as it leads people to think it is procedural like C. Borrowing the C syntax is fine for expressions but something like JSON might have been better for geometry as that would clearly be a description and nobody would be expecting to be able to mutate things.


On 21 September 2014 01:06, laird <[hidden email]> wrote:
Perhaps it's just me, but using words feels more natural on multi-line
expressions, and the ?: feels more natural packed into a one-liner (e.g. a
small function).

Would it be too evil to ask that OpenSCAD support both phrasings? Not
strictly necessary, of course, but while ?: is more compact, the Python
phrasing is more readable.



--
View this message in context: http://forum.openscad.org/Re-OpenSCAD-Digest-Vol-58-Issue-33-tp9702p9747.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: OpenSCAD Digest, Vol 58, Issue 33

MichaelAtOz
Administrator
Perhaps a consideration for OpenSCAD V2/3000?
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

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

Re: OpenSCAD Digest, Vol 58, Issue 33

Alan Cox
In reply to this post by nophead
On Sun, 21 Sep 2014 00:54:05 +0100
nop head <[hidden email]> wrote:

> Well OpenScad borrows its syntax from C and that is how C does it, which is
> handy if you are a C programmer as you don't have to learn anything new,
> including the fact it has the lowest precedence of all operators.
>
> Python does:
>
> value = x if c else y
>
> Which is a different order and perhaps more natural.

VHDL also provides something similar but with an important useful twist.
It's not an "if" but a "when", in other words value basically acts like a
function. You can also put multiple conditions in one go fairly cleanly
as you can say the equivalent of

          value = x when c1 else y when c2 else z when c3 else other;

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