On 8/24/25 07:50, Jon Bondy via Discuss wrote:

An example of MyCube() plz?

I can't imagine anything better than loading the stack with at least 4
vars, using syntax like mycube([x,y,z,1|0]); where the "0|1" is true|false.
There may be better ways my ancient brain hasn't thought of.  Surely
that would be disastrous in terms of render time in a recursive or
animation program.

Cheers, Gene Heskett, CET.

"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

On Sun, Aug 24, 2025 at 08:47:20AM -0400, gene heskett via Discuss wrote:

module MyCube (size, center=true)
{
cube (size, center);
}

module MyCube (sizec)
{
cube ([size[0], size[1], size[2]], center=size[3]);
}

or:

module MyCube (sizec)
{
center=isset(size[3]) ? size[3] : true;
cube ([size[0], size[1], size[2]], center=center);
}

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ  Delfgauw, The Netherlands.
** KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a** is going up.  -- Chris Hadfield about flying up the space shuttle.
**  'a' for accelleration.

On 8/24/25 08:56, Rogier Wolff via Discuss wrote:

where the call would look like MyCube([a,b.c]); ?

Both examples are even more typing. More LOC
(and typu magnets) to get the job done.

I don't see in the current cheat sheet, how a 3 value array is made so
it passes as one named sizec? Not (to me) obvious.

I can see it in a "list" category, sort of. And I  assume it follows
"scope" rules.

But what is "isset"? that keyword does not exist in the current cheat
sheet.
But from the above, I gather that it could be useful albeit more typing.

Thank you Roger.

Cheers, Gene Heskett, CET.

"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

On 8/24/2025 2:17 AM, pca006132 via Discuss wrote:

Don't use the word "function", because that word has a specific meaning
in OpenSCAD, but yes, if I'm reading what you're saying correctly.

Just as today you can say:

addOne = function (x) x + 1;
echo(addOne(5));

you should be able to say something like:

cubeSphere = module () { sphere(r=10); cube(15, center=true); };
cubeSphere();

Note that in that second snippet cubeSphere is not a function, because
in OpenSCAD functions and modules are separate mechanisms.

At BOSL laboratories, we've been wishing for this feature for about a decade.  It would make our software implementations of union() / difference() / intersection() / offset() far faster (and somewhat less buggy), and it would make a 3D version feasible (in reasonable time) for VNFs.  And yes, bend would become better.

• Revar

Any reason why not? It is very odd to have module reference that is a Value but you can't use it in an expression? It makes the language very strange and unpredictable?

Is there a special reason why we keep statements and expressions so different? I am rather intrigued for the reason about the invocation order.

But anyway, I think I am not going to touch this area anyway ...

Peter

On 8/25/25 5:52 AM, Peter Kriens via Discuss wrote:

Among any other reasons, it's because OpenSCAD has at least 4
environments for names: functions, modules, assignments, and specials.
If there is a call on a name (i.e. name()) then if it's a special name,
look it up in the special environment regardless of statement vs
expression. If it's in an expression, look it up in the function
environment first and then the assignment environment if not found in
the function environment. If it's a statement, look it up module
environment (modules as Values needs to add a lookup into assignments
when it fails to be found in module environment and obviously(?) allow
an expression as a name).

So if you change that you're breaking stuff.

• Cory

On 8/25/2025 2:52 PM, Peter Kriens wrote:

Because it doesn't align with the overall pattern of the language. 
Modules are modules; they do not go in expressions.

I don't think the implementation would be at all amenable to calling
modules from expressions.  From an external point of view, as you noted
there's nothing meaningful for them to return, making it odd to put them
into an expression.

You absolutely can use module references in expressions.  You can assign
them, put them into arrays, str() them, echo() them, pass them to
functions, et cetera.  You just can't invoke them, because you can't
invoke modules from expressions.

You'd have to ask Marius.  My guess is that the answer is in the
evolution of the language, and in particular the desire to support the
command line's -D option.  At this point, though, it's pretty well
embedded into the language.

Again, my bet is that it's tied up in the desire to support -D.

Also, conceptually, OpenSCAD operations are only sort of ordered.  With
the exception of assert() and the ordering of echo() output, it would be
entirely legal for OpenSCAD to evaluate modules in any order.    With
similar exceptions, it would be legal to evaluate assignments in any
order that preserves the dependency relationship.  In theory this would
allow automatic multithreaded execution, though in practice historically
render time has been so much larger than execution time that nobody has
done it.

Good plan.