On 23.10.22 20:21, nop head wrote:

That does not need module references as shown in (incomplete)
https://github.com/openscad/openscad/pull/3956 - just normal
modules will do.

It "only" needs render() as function so it can return data
instead of geometry.

The challenge is more defining the data structure and exact
behavior to be as future proof as possible.

ciao,
Torsten.

That seems more disruptive because it mixes module syntax into expressions.
A module reference is just a value, so can naturally be passed to a
function.

On Sun, 23 Oct 2022 at 19:29, Torsten Paul Torsten.Paul@gmx.de wrote:

On 23.10.22 20:33, nop head wrote:

Having the more general form is probably nicer, I'm just saying
it's not required to have references. Also I don't think it's
that disruptive as it basically follows the normal chained style
of modules, just bridging the existing gap between functions and
modules which is exactly the point.

With the other discussion around objects / module literals or
whatever those will be called taking up speed maybe it's not
needed to have the in-between solution.

ciao,
Torsten.

Module references are needed for polymorphism, etc, just as function
references. I would currently draw a configurable hot end with enums and a
switch statement but neither exist, so random constants and if then else,
ugly.

On Sun, 23 Oct 2022 at 20:14, Torsten Paul Torsten.Paul@gmx.de wrote:

On 10/23/2022 1:14 PM, nop head wrote:

Yes, but module references, like function references, are not very
interesting without parameters.

What is needed is a way to get geometry into expression context. 
Whether that is via a "geometry literal" mechanism or via a way to call
a module like you would call a function, it is geometry values that are
interesting.