Empty group counts as child.
Marius said: "The underlying reason for this is that “if” is not a language
construct, it’s a built-in module. Since it’s a module, it always returns a
node, even when it has no children, similar to an empty union."
My suggestion is to treat "if" as a language construct, consistent with how
"if" is treated in a list comprehension.
Just as
[..., if (false) expr, ...]
does not add any elements to the list under construction, so should
{...; if (false) shape_expr; ...}
not add any shapes or groups to the group under construction.
On 25 November 2017 at 12:11, Marius Kintel marius@kintel.net wrote:
On Nov 25, 2017, at 10:58 AM, nop head nop.head@gmail.com wrote:
They totally bloat out the CSG view and make $children report the wrong
number. But why create them in the first place? Why does an if that is
false need to create anything?
The underlying reason for this is that “if” is not a language construct,
it’s a built-in module. Since it’s a module, it always returns a node, even
when it has no children, similar to an empty union.
Changing the contract of modules to optionally return nothing is possible.
Pruning empty sub trees is also a possible post-processing step.
Another option would be to see this in connection with the old "implicit
union” story, whose work-in-progress suggests allowing modules to return a
(possibly empty) list of nodes, where emptyness is something we can manage
in a better way: https://github.com/openscad/openscad/issues/350
-Marius
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Yes It should be a language construct. How many other bits of language are
modules? and would they benefit from not being?
On 26 November 2017 at 19:04, doug moen doug@moens.org wrote:
Marius said: "The underlying reason for this is that “if” is not a
language construct, it’s a built-in module. Since it’s a module, it always
returns a node, even when it has no children, similar to an empty union."
My suggestion is to treat "if" as a language construct, consistent with
how "if" is treated in a list comprehension.
Just as
[..., if (false) expr, ...]
does not add any elements to the list under construction, so should
{...; if (false) shape_expr; ...}
not add any shapes or groups to the group under construction.
On 25 November 2017 at 12:11, Marius Kintel marius@kintel.net wrote:
On Nov 25, 2017, at 10:58 AM, nop head nop.head@gmail.com wrote:
They totally bloat out the CSG view and make $children report the wrong
number. But why create them in the first place? Why does an if that is
false need to create anything?
The underlying reason for this is that “if” is not a language construct,
it’s a built-in module. Since it’s a module, it always returns a node, even
when it has no children, similar to an empty union.
Changing the contract of modules to optionally return nothing is
possible. Pruning empty sub trees is also a possible post-processing step.
Another option would be to see this in connection with the old "implicit
union” story, whose work-in-progress suggests allowing modules to return a
(possibly empty) list of nodes, where emptyness is something we can manage
in a better way: https://github.com/openscad/openscad/issues/350
-Marius
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Nov 26, 2017, at 3:06 PM, nop head nop.head@gmail.com wrote:
Yes It should be a language construct. How many other bits of language are modules? and would they benefit from not being?
Quite a few. The language of OpenSCAD is really quite minimal.
The language, in its entirety, as Doug has lobbied extensively for, is ripe for a redesign. Some of this is possible to do through iteration and some will eventually require us to break backwards compatibility.
Switching out if-else statements from being modules to being language constructs, while marking that switch as experimental, is a pretty low-risk endeavor. if-else is already managed by the parser, so this is mostly about separating modules from these statements on the AST level.
-Marius
It appears that someone is tinkering with Nabble.
To me the Forum looks inoperative.
When you click the Post button on a reply or new topic you get this:
and the post is not committed.
I've reported it to Nabble support:
http://support.nabble.com/Another-NAML-change-redirect-to-td7599057.html (lower down)
Could someone else please try to post just to confirm it is not something re my account setup.
Until it is fixed use the mailing-list.
MichaelAtOz
Forum Admin - when it works.
I don't claim to grok all of the implications, and I certainly know
nothing of the implementation, but empty nodes seem useful to represent
placeholders in the "argument list" that the children represent.
// make first child red, second child green, third child blue
module rgb() {
color("red") children(0);
color("green") children(1);
color("blue") children(2);
}
rgb() { // only wants green and blue children
union() ; // or anything that emits an empty node
translate([1,1,1]) sphere(1);
translate([2,2,2]) sphere(1);
}
or
red = true;
green = false;
blue = true;
rgb() {
if (red) sphere(1);
if (green) translate([1,1,1]) sphere(1);
if (blue) translate([2,2,2]) sphere(1);
}
It does seem simple and consistent that every statement produces exactly
one node. Unfortunately, not always adequate - consider the need for
intersection_for(). I am not sure whether the simplicity and
consistency outweighs the flexibility of allowing some statements to
produce zero nodes (and some to produce more than one?).
It does seem simple and consistent that every statement produces exactly one node. Unfortunately, not always adequate - consider the need for intersection_for(). I am not sure whether the simplicity and consistency outweighs the flexibility of allowing some statements to produce zero nodes (and some to produce more than one?).
My view is that intersection_for() is a hack to work around exactly this.
In the work-in-progress branch for #350, intersection_for() has been deprecated: https://github.com/openscad/openscad/issues/350
That branch does break a bunch of stuff so I lost momentum implementing it as I haven’t found a good point in time to introduce such changes, or found a middle ground that maintains current behavior for existing designs.
-Marius