Any where to find the doc for lc-each, lc-else and lc-for-c ?
Parkinbot wrote
Ronaldo wrote
(and we cannot use use
?:
inside any expression anymore as it happens currently with
if-without
)
can you elaborate on this? And on, what will
if/else
gain instead, when it is allowed in any expression?
In the current stable version, the filter if cannot be an operand of any
LC expression, it must wrap expressions. Or as adrian has said it must be at
top level. In fact, any current LC filter may be written with only one if
in the form: if(cond) <expression> where <expression> has no filter. That
is why I don't see the filter if as a operator but as a data flow control:
it may not deliver a data.
If we just change ?: to accept filtered operands, it will not be an
operator anymore and cannot be used as an operand of other operators. It
will have the same property the filter *if *has, that is it must wrap
expressions as it may not deliver a data. Instead of a gain, we loose the
ternary operator.
A few month ago, I asked in another thread why *if *in the context of LC
could not have an else clause. And I was introduced to the snapshot
version if-else. To me at that time seemed natural to have both ?: and
if-else with different natures and usages. And it still is.
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18920.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo wrote
If we just change
?:
to accept filtered operands, it will not be an operator anymore and
cannot be used as an operand of other operators. It will have the same
property the filter
if
has, that is it must wrap expressions as it may not deliver a data.
Instead of a gain, we loose the ternary operator.
This view is NOT correct. The operator ?: will not be touched at all. Just
its value-range will be extended by one additional symbol, so that it can
return a value, which may be interpreted as not-in-list when LC finally
composes the list. The operator may be nested as you like and used as
before. No change in semantics. Just one more symbol is introduced.
Ever tried this?
echo( false?undef: "Hi"); // Hi
echo( true?undef: "Hi"); // undef
echo( undef?undef: "Hi"); // Hi
What would you expect to happen, when it encounters a nil? Exactly the
same, but nil instead of undef. No explosion.
undef may be used with any other operator
echo(10+undef); // undef
echo(undef*undef); // undef
So what makes you afraid of just a new symbol nil, which will only show
up, when you explicitly denote it? It lets you write your filter using
if-without at any nested position with no nil showing up at all.
The only logic that will change, is that if-without will have to return
nil. Without knowing the actual implementation of if-without, I'm pretty
sure that it does return some value indicating a nothing (using an exception
instead is possible but not indicated). With nil this value gets a name
and will show up in the language.
cond1?
cond2? if(cond3) res0
:res1
:res2
So you can use ?: exactly as before and it will work as before. You /may
/denote nil in LC, but you get along without ever seeing it.
I really don't get your skeptsism.
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18924.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo wrote
If we just change
?:
to accept filtered operands, it will not be an operator anymore and
cannot be used as an operand of other operators. It will have the same
property the filter
if
has, that is it must wrap expressions as it may not deliver a data.
Instead of a gain, we loose the ternary operator.
No that's not true again. A "?:" to accept "if-filter" only means to filter
one of its branch, the entire "?:" remains an operator. A construct like:
[ for(...) A?B:if(C)D ]
will at least return one branch, which is EXACTLY LIKE: [ for(...)
if(A)?B:if(C)D ]
$ Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), synwrite ( 2 ); $ tips: hash ( 2 ), matrix ( 2 , 3 ), sweep ( 2 , 3 ), var ( 2 ), lerp , animation ( gif , prodVid , animlib ), precision ( 2 ), xl-control , type , rounded polygon , chfont , tailRecur ( 2, 3 ), isosphere ( 2 ), area , vol/center , RGB , CurvedImg , tests ( 2 ); $ Apps: rollApp , blockscad , openjscad , on AWS ( pdf )
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18925.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
x = [ z[1+2*round(A?B:if(C) d)] ];
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18927.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo wrote
x = [ z[1+2*round(A?B:if(C) d)] ];
Let me note that indexing ist no LC!
You can test your example setting undef instead of nil shortcutting the
evil filter result. z[nil] will be *nil *and [nil] evaluates to [].
To see what a language can do silently, look at this (which throws a runtime
error in other languages):
z = [1,2,3]; echo(z[1.1]); // 2
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18930.html
Sent from the OpenSCAD mailing list archive at Nabble.com.