I think we need to be clear on what's becoming first-class here - a module, or geometry. You give only simple examples.  In those examples, it *looks* like what you're moving around is geometry, but you keep saying "module" so I'm not clear. The distinction is in when execution occurs. If you're manipulating geometry, you need to fully supply arguments, and the geometry is generated (but not added to the model) at the time that you mention it. If, on the other hand, you're manipulating references to modules, then the arguments would be supplied at a later invocation. Totally making up syntax, I'd think that the two would look sort of like a = cube(10); And then there would be something that says "add a to the model".  a() wouldn't really be right, because a does not represent an executable object; it does not have arguments. versus b = module (size) { cube(size); } b(10); Do you understand the distinction I'm drawing? My thinking in this area has been around manipulating geometry.  That's not to say that manipulating module references would be wrong - just different.

Jordan Brown wrote: > I think we need to be clear on what's becoming first-class here - a > module, or geometry. > > You give only simple examples.  In those examples, it *looks* like what > you're moving around is geometry, but you keep saying "module" so I'm > not clear. > > The distinction is in when execution occurs. > In the post I have listed 7 things you can do with the module alias, 6 of which don’t instantiate into the CSG tree. I’m not sure I can make it any clearer, but I will try > 1. You can create a variable representing a module, ***without instantiating it into the CSG tree***. > > 2. You can access member attributes of the module, ***without instantiating it into the CSG tree***. > > 3. You can use modules as member attributes of a parent module ***without instantiating it into the CSG tree***. > > 4. You can pass a module to a function ***without instantiating it into the CSG tree***. > > 5. You can return a module from a function ***without instantiating it into the CSG tree*** > > 6. You can put a module into a list or dictionary etc ***without instantiating it into the CSG tree*** > > 7. ***You can also instantiate the module into the CSG tree*** using the existing function call syntax as with any other module > > If you're manipulating geometry, you need to fully supply arguments, and > the geometry is generated (but not added to the model) at the time that > you mention it. > > > Not manipulating geometry > > If, on the other hand, you're manipulating references to modules, then > the arguments would be supplied at a later invocation. > > > sounds quite close to what i am doing > > Totally making up syntax, I'd think that the two would look sort of like > > a = cube(10); Try that in current and proposed openscad and you will get WARNING: Ignoring unknown function 'cube' in file , line 2 because the grammar distinguishes anything that returns something as a function while cube(10); is a statement and so openscad sees that invocation as instantiating a module > > And then there would be something that says "add a to the model".  a() > wouldn't really be right, because a does not represent an executable > object; it does not have arguments. > > versus > > b = module (size) { cube(size); } > b(10); > > Do you understand the distinction I'm drawing? See above. cube() as statement or as expression statement -> instantiate a module expression -> function call > > > My thinking in this area has been around manipulating geometry.  That's > not to say that manipulating module references would be wrong - just > different. Manipulating references is basically what I am doing,

In the grammar , the module_instantiation is represented by the non-terminal [single_module_instantiation](https://github.com/openscad/openscad/blob/master/src/core/parser.y#L323 "single_module_instantiation") which is a [statement](https://github.com/openscad/openscad/blob/master/src/core/parser.y#L183 "statement") The single_module_instantiation is a [side effect](https://en.wikipedia.org/wiki/Side_effect_(computer_science) "side effect"). (As a rule any function that returns nothing is likely to have side effects) The side effect of module_instantiation in this case is to instantiate the module or in other words to add a piece of geometry to the CSG tree. Currently in Openscad, you can only define a module or instantiate it. The purpose of the proposed module_alias feature is that you can manipulate the module in various ways (some of which are listed in items 1 to 6 in the OP) without side_effects. You can also however instantiate the module referred to by the module_alias if and when you wish, using the same syntax as used for a module.