if(false) returns empty object in RC3, breaks code from 2019.05

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: if(false) returns empty object in RC3, breaks code from 2019.05

nophead
Not quite because if(true) echo() has changed to return the empty set.

On Thu, 7 Jan 2021 at 03:34, adrianv <[hidden email]> wrote:
In RC4, if (false) doesn't create a group in the tree, so intersection works
the way it did before. 


JordanBrown wrote
> [ Sigh.  Not my day.  First I sent this from the wrong address, then
> when I went to resend it from the right address I resent the one of
> Adrian's messages instead of this one. ]
>
> On 12/26/2020 6:58 PM, adrianv wrote:
>> JordanBrown wrote
>>>> It seems like the truth is that passing assert or echo as children is
>>>> just weird and confusing.
>>> Somewhat.  But they obey the general rule:  they run when you say
>>> children(i) and refer to them.
>> Yes, everything makes sense if you understand the technical details.  But
>> for a casual user it's going to be surprising and puzzling, I think.
>
> Yes.
>
> What I'm saying is that if it's going to be surprising and puzzling, at
> least there should be a simple rule.
>
> (And I think that all variations that have gotten past the first level
> of discussion have that simple rule, that all module-like invocations
> yield children.)
>
>> I think in my own work I'd be more inclined to stick a cube() or
>> something in as a placeholder than text. Or just a comment.
>
> A comment won't be enough if you're leaving a placeholder for child #3 of
> 6.
>
>>>> which already exists, like it or not.
>>> Well, in the RC, which is 95% existing but not 100%.  (I think my
>>> primary contribution to this discussion might be in giving it a name.)
>> What is the missing 5%? 
>
> I wasn't saying that the functionality wasn't in the RC... but rather
> that the RC is an RC, not a release, so doesn't 100% exist.  Behavior in
> a non-release can change; behavior in a release should normally remain
> constant.
>
> (But:  the RC has NULL functionality for echo, assert, intersection, and
> difference, but not for if, for, and modules.  Hans has a PR for if.)
>
>> [ if(true)echo() and if(false)echo() are different from echo() ]
>> Wouldn't these things be "fixed" by having if statements not create
>> geometry? 
>
> Well, by having failing if not generate geometry - having it generate
> NULL - and by having successful if (or else) yield whatever its contents
> yield (which might or might not be NULL).
>
>> I'm in agreement that intersection with empty set should give the
>> empty set.  The problem is that there's no way to specify the
>> complement of the empty set. So I can't do
>> intersection(){
>>    if (condition) thing(); else everything();
>>    otherthing();
>> }
>
> NULL would address this particular need, because a failing if would
> yield NULL, and intersection would be defined to ignore NULL.  So for
> intersection purposes, NULL would be sort of like everything().
>
>> For difference, yes, it matters what the first object is, and your
>> example
>> does give a case where things change.  But it's not an example that seems
>> like it has a use case.
>
> Agreed.  It only has a confusion case, where somebody has put an echo()
> as the first child to a difference.
>
>
>> I'm left wondering if it really matters whether if(false) and empty
>> for return an empty set or a NULL, since most of the time it will give
>> the same result anyway.
>
> Intersection is the big one.
>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: if(false) returns empty object in RC3, breaks code from 2019.05

adrianv
I'm not sure how the behavior of "if (true)..." can make my statement about
"if (false)" incorrect.  

That behavior has stayed the same between RC3 and RC4.  And in 2019.05
if(true) echo(..) produces an empty set as well, though it's a different
looking empty set.  We get group(){group();} in 2019 and now just group(){};
It looks like "if (true)" always makes a group.  So in all the versions, "if
(true) {}" produces group();.  It's just that in the RC if you stick an echo
as a child it adds nothing.  


nophead wrote
> Not quite because if(true) echo() has changed to return the empty set.
>
> On Thu, 7 Jan 2021 at 03:34, adrianv &lt;

> avm4@

> &gt; wrote:
>
>> In RC4, if (false) doesn't create a group in the tree, so intersection
>> works
>> the way it did before.
>>
>>
>> JordanBrown wrote
>> > [ Sigh.  Not my day.  First I sent this from the wrong address, then
>> > when I went to resend it from the right address I resent the one of
>> > Adrian's messages instead of this one. ]
>> >
>> > On 12/26/2020 6:58 PM, adrianv wrote:
>> >> JordanBrown wrote
>> >>>> It seems like the truth is that passing assert or echo as children
>> is
>> >>>> just weird and confusing.
>> >>> Somewhat.  But they obey the general rule:  they run when you say
>> >>> children(i) and refer to them.
>> >> Yes, everything makes sense if you understand the technical details.
>> But
>> >> for a casual user it's going to be surprising and puzzling, I think.
>> >
>> > Yes.
>> >
>> > What I'm saying is that if it's going to be surprising and puzzling, at
>> > least there should be a simple rule.
>> >
>> > (And I think that all variations that have gotten past the first level
>> > of discussion have that simple rule, that all module-like invocations
>> > yield children.)
>> >
>> >> I think in my own work I'd be more inclined to stick a cube() or
>> >> something in as a placeholder than text. Or just a comment.
>> >
>> > A comment won't be enough if you're leaving a placeholder for child #3
>> of
>> > 6.
>> >
>> >>>> which already exists, like it or not.
>> >>> Well, in the RC, which is 95% existing but not 100%.  (I think my
>> >>> primary contribution to this discussion might be in giving it a
>> name.)
>> >> What is the missing 5%?
>> >
>> > I wasn't saying that the functionality wasn't in the RC... but rather
>> > that the RC is an RC, not a release, so doesn't 100% exist.  Behavior
>> in
>> > a non-release can change; behavior in a release should normally remain
>> > constant.
>> >
>> > (But:  the RC has NULL functionality for echo, assert, intersection,
>> and
>> > difference, but not for if, for, and modules.  Hans has a PR for if.)
>> >
>> >> [ if(true)echo() and if(false)echo() are different from echo() ]
>> >> Wouldn't these things be "fixed" by having if statements not create
>> >> geometry?
>> >
>> > Well, by having failing if not generate geometry - having it generate
>> > NULL - and by having successful if (or else) yield whatever its
>> contents
>> > yield (which might or might not be NULL).
>> >
>> >> I'm in agreement that intersection with empty set should give the
>> >> empty set.  The problem is that there's no way to specify the
>> >> complement of the empty set. So I can't do
>> >> intersection(){
>> >>    if (condition) thing(); else everything();
>> >>    otherthing();
>> >> }
>> >
>> > NULL would address this particular need, because a failing if would
>> > yield NULL, and intersection would be defined to ignore NULL.  So for
>> > intersection purposes, NULL would be sort of like everything().
>> >
>> >> For difference, yes, it matters what the first object is, and your
>> >> example
>> >> does give a case where things change.  But it's not an example that
>> seems
>> >> like it has a use case.
>> >
>> > Agreed.  It only has a confusion case, where somebody has put an echo()
>> > as the first child to a difference.
>> >
>> >
>> >> I'm left wondering if it really matters whether if(false) and empty
>> >> for return an empty set or a NULL, since most of the time it will give
>> >> the same result anyway.
>> >
>> > Intersection is the big one.
>> >
>> >
>> > _______________________________________________
>> > OpenSCAD mailing list
>>
>> > Discuss@.openscad
>>
>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: if(false) returns empty object in RC3, breaks code from 2019.05

nophead
Yes but in the last release empty groups were ignored in intersection and difference, so adding an echo did not break them. A plain echo now does not break them but if() echo() does if it is true but not false. And a wrapped echo in a module now breaks intersection and difference.

On Thu, 7 Jan 2021 at 11:25, adrianv <[hidden email]> wrote:
I'm not sure how the behavior of "if (true)..." can make my statement about
"if (false)" incorrect. 

That behavior has stayed the same between RC3 and RC4.  And in 2019.05
if(true) echo(..) produces an empty set as well, though it's a different
looking empty set.  We get group(){group();} in 2019 and now just group(){};
It looks like "if (true)" always makes a group.  So in all the versions, "if
(true) {}" produces group();.  It's just that in the RC if you stick an echo
as a child it adds nothing. 


nophead wrote
> Not quite because if(true) echo() has changed to return the empty set.
>
> On Thu, 7 Jan 2021 at 03:34, adrianv &lt;

> avm4@

> &gt; wrote:
>
>> In RC4, if (false) doesn't create a group in the tree, so intersection
>> works
>> the way it did before.
>>
>>
>> JordanBrown wrote
>> > [ Sigh.  Not my day.  First I sent this from the wrong address, then
>> > when I went to resend it from the right address I resent the one of
>> > Adrian's messages instead of this one. ]
>> >
>> > On 12/26/2020 6:58 PM, adrianv wrote:
>> >> JordanBrown wrote
>> >>>> It seems like the truth is that passing assert or echo as children
>> is
>> >>>> just weird and confusing.
>> >>> Somewhat.  But they obey the general rule:  they run when you say
>> >>> children(i) and refer to them.
>> >> Yes, everything makes sense if you understand the technical details.
>> But
>> >> for a casual user it's going to be surprising and puzzling, I think.
>> >
>> > Yes.
>> >
>> > What I'm saying is that if it's going to be surprising and puzzling, at
>> > least there should be a simple rule.
>> >
>> > (And I think that all variations that have gotten past the first level
>> > of discussion have that simple rule, that all module-like invocations
>> > yield children.)
>> >
>> >> I think in my own work I'd be more inclined to stick a cube() or
>> >> something in as a placeholder than text. Or just a comment.
>> >
>> > A comment won't be enough if you're leaving a placeholder for child #3
>> of
>> > 6.
>> >
>> >>>> which already exists, like it or not.
>> >>> Well, in the RC, which is 95% existing but not 100%.  (I think my
>> >>> primary contribution to this discussion might be in giving it a
>> name.)
>> >> What is the missing 5%?
>> >
>> > I wasn't saying that the functionality wasn't in the RC... but rather
>> > that the RC is an RC, not a release, so doesn't 100% exist.  Behavior
>> in
>> > a non-release can change; behavior in a release should normally remain
>> > constant.
>> >
>> > (But:  the RC has NULL functionality for echo, assert, intersection,
>> and
>> > difference, but not for if, for, and modules.  Hans has a PR for if.)
>> >
>> >> [ if(true)echo() and if(false)echo() are different from echo() ]
>> >> Wouldn't these things be "fixed" by having if statements not create
>> >> geometry?
>> >
>> > Well, by having failing if not generate geometry - having it generate
>> > NULL - and by having successful if (or else) yield whatever its
>> contents
>> > yield (which might or might not be NULL).
>> >
>> >> I'm in agreement that intersection with empty set should give the
>> >> empty set.  The problem is that there's no way to specify the
>> >> complement of the empty set. So I can't do
>> >> intersection(){
>> >>    if (condition) thing(); else everything();
>> >>    otherthing();
>> >> }
>> >
>> > NULL would address this particular need, because a failing if would
>> > yield NULL, and intersection would be defined to ignore NULL.  So for
>> > intersection purposes, NULL would be sort of like everything().
>> >
>> >> For difference, yes, it matters what the first object is, and your
>> >> example
>> >> does give a case where things change.  But it's not an example that
>> seems
>> >> like it has a use case.
>> >
>> > Agreed.  It only has a confusion case, where somebody has put an echo()
>> > as the first child to a difference.
>> >
>> >
>> >> I'm left wondering if it really matters whether if(false) and empty
>> >> for return an empty set or a NULL, since most of the time it will give
>> >> the same result anyway.
>> >
>> > Intersection is the big one.
>> >
>> >
>> > _______________________________________________
>> > OpenSCAD mailing list
>>
>> > Discuss@.openscad
>>
>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12