On 4/19/23 05:39, Rob Ward wrote:

Not an expert, or even a spurt, the only variable variable I know and
use in OpenSCAD is the i(could be anything) in the for constuct which
can be used for other things within the scope of the for statement.

Like drawing a circle of bolt holes using polar/rectangular conversion
to place the bolt holes. Handier than bottled beer IMNSHO. In one bit of
code I use the same function, with 3 passed arguments, to place a self
tapping in plastic machine screw hole, another following call places the
clearance hole in the mating part, and a third call places the
countersink for the head of that screw so the head sits just below the
surface. I've put bolts in some crazy places that way. A 4th argument
could just as easily control the functions $fn, to place countersunk
nuts.  A 5th,6th.7nth argument could move the translate statement into
the subroutine, but that begins to resemble a bowl of well cooked pasta.
I also haven't a clue how much room on the stack there is for some of
this. I've not found a limit if there is one.

Cheers, Gene Heskett.

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis
  Genes Web page http://geneslinuxbox.net:6309/

On 4/19/23 09:28, Torsten Paul wrote:

+5 ;o)>

Cheers, Gene Heskett.

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis
  Genes Web page http://geneslinuxbox.net:6309/

On 4/19/23 13:07, gene heskett wrote:

To add to the multicore debate, OpenSCAD seems to be a single core at a
time software, but the os can and will move it to a cooler core when the
one its using heats up. I watch it with gkrellm, and can see the os
bouncing openscad from core to core if my project is big and poorly written.

Cheers, Gene Heskett.

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis
  Genes Web page http://geneslinuxbox.net:6309/

On 4/19/2023 12:56 AM, Rob Ward wrote:

For better or worse, OpenSCAD variables ... don't vary.

It's possible to have a language that looks a lot like OpenSCAD where
the variables vary, but it would be a different and probably
incompatible language.  It isn't clear to me how much effort it would be
to modify the OpenSCAD program to support that language.  It would not
be trivial.

Why would it be incompatible?  Because assignments in OpenSCAD
always create new instances of variables; previous instances are
unchanged.

    x = 0;
    if (true) {
        x = 1;
    }
    echo(x);

is defined in OpenSCAD to print 0, and most "allow variables to
vary" schemes would have it print 1.

There is a related trick, using list comprehensions and "C-style" for. 
Here's a running-sum function using it.

a = [1,2,3];
function runningSum(a) = [
    for(i=0, t=0; i < len(a); t=t+a[i],  i=i+1) t+a[i]
];
echo(runningSum(a));

Although this appears to violate the "variables don't vary" rule, it can
be viewed as having each iteration be a new scope, with access to the
variables from the previous iteration, just as it is perfectly legal to
have a new scope say "x=x+1", creating a new tighter-scoped x from the
outer-scope x.  (But my experimentation suggests that it does indeed
violate the rule.)

On 19.04.23 20:00, Father Horton wrote:

A while ago Doug proposed a compromise that might not be an
actual huge change and most importantly a change that does
not impact the handling of closures for function literals
and other global behavior: local variables.

This promises easier translation of algorithms that use
changing variables without the need for a totally different
behavior.

ciao,
Torsten.

In defense of Functional Programming for this task type, the immutability of “variables” does lend itself to multi-threading. There is even evidence that OpenSCAD may be able to take advantage of that eventually. Some day.

Memoization could make for some nice improvements too.

-Revar

On 4/19/2023 10:40 AM, Jordan Brown wrote:

And that's not even the strangest established behavior in OpenSCAD.

Here's an exercise for the reader.  What does the following program
output?  Why?

x = 0;
if (true) {
    echo(x);
    x = 1;
}

There's a lot of ways that OpenSCAD is an unusual language, and is stuck
being that language for compatibility reasons.  Changing these
behaviors would make it a different and incompatible language.

Not that it can't be done... but it would be a different language.