doug.moen wrote

That's true. Thx.

Yes, the inconsistency is another problem of having "if-else" in a lc
(other than being confusing with the "if" filter).

But we already have a "?:" in the statement level:

a = A?B:C

Now we are gonna invent another one, which is more complicated, like this:

a = if(A) B else C

just for the purpose of being consistent with the "/if(A)B else C/ ternary
operator"
in the lc ? That looks like a reversed engineering to me.

If we had allowed "A?B:C" to take the "if" filter, [ for(...)A?B:if(C)D ],
which is just one step, we wouldn't have to make a big circle to firstly
invent
an "if-else" ternary operator in the lc context, then secondly make a new
construct that is more complicated than the one we already have in the
statement level (that's two steps).

$  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-tp18823p18873.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Parkinbot wrote

i c. But, your proposal of "a==v? a : null" is not the same as
"if(a==v)a:if(b)c", 'cos it only divides items into two groups, one is
returned, one is dropped (filtering). The "if(a==v)a:if(b)c" one, on the
other hand, divides items into 2 groups (branching), one is returned, the
other then subject to the filtering (that is, further divided into accepted
items and dropped items (filtering)).

The first one is only filtering, the 2nd one is branching+filtering:

[ f(...) a==v?a:null ]

would be the same as:

[ f(...) if(a==v) a ]

it doesn't have the functionality of branching+filtering.

$  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-tp18823p18874.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

The reason I say it is alien is because Python already has list
comprehensions with if else and if else in expressions but doesn't have a
weird version of the C ternary operator with a null in it. Does any
language have that?

On 2 November 2016 at 17:13, runsun runsun@gmail.com wrote:

runsun wrote

Wait, come to think of it, it is possible for it to have both branching and
filtering:

so your right, it is do-able.

I still think a [ for(...) a==A?a:if(a==B)C ] is more readable, though.

$  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-tp18823p18876.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

nophead wrote

Not that I know of. But, like I said, any new feature is alien to some
users.

$  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-tp18823p18877.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

runsun wrote

nested ?: ARE ugly. But this operator is already part of the language and
you can't get rid of it any more. Bringing in a "cuter" one, doesn't do away
with it. So better make the best out of it.

For the null symbol: It is a value like any other e.g. undef, but it
will be interpreted (=omitted) by LC as well by any other operator (e.g. as
neutral element). So an echo() within LC (which is not yet available)
would prompt it, but outside it'll be gone.

Usually one would interpret *null *as 0 in number context. But it is
possible to also implement some neutral element magic, overriding it for any
interesting operator:

and so on.

--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18878.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Parkinbot wrote:

I agree. Especially when you have to write a large, multi-line conditional
within a function. That's the situation where if-else expressions will add
a lot of readability to the language.

Once we have if-else conditionals supported everywhere (statements, list
comprehensions and statements), then we'll have a consistent syntax for
conditionals, and there won't be any more confusion about "when do I use
if-else" vs "when do I have to use ?: instead".

Every functional programming language already uses if-else for conditional
expressions, even Python uses if-else for conditional expressions, so we
aren't breaking any new ground here.

I don't see any justification for creating a new symbol "null" with
different meanings in different contexts, just so that we can type
"a?b:null" as an alternative to "if(a)b". The already existing syntax that
uses "if" is more readable, because the syntax is familiar. Every existing
programming language already uses the "if" and "else" keywords, so we
should use that, instead of creating something new.

I don't think that
(x != 0) ? cube(x) : null;
is an improvement over
if (x != 0) cube(x);
at the statement level, and it's the same argument for list comprehensions.
It's pretty standard to use 'if' for conditionals in list comprehensions,
there are no languages that use ?: in this context.

On 2 November 2016 at 14:29, Parkinbot rudolf@parkinbot.com wrote:

2016-11-02 18:29 GMT-02:00 doug moen doug@moens.org:

So you suggest to extend "if-else" as a conditional expression to statements
and lc but to keep "if-without else" just as a filter in the context of lc,
do you? That sounds nice.

Well stated Doug, I couldn't agree more.

On 2 November 2016 at 20:29, doug moen doug@moens.org wrote:

I am able to program with both, as I can live with many other crudities of
OpenSCAD. That is not the point.

In language design it is quite easiy (and tempting) to introduce new stuff
and also redundancy. But one should never forget that it is almost
impossible to get rid of stuff already introduced, language incongruities,
and premature hacks. So why was ?: initially introduced, if if/else is
so popular?

Look at:

Which value will a get, if b is false?

--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18891.html
Sent from the OpenSCAD mailing list archive at Nabble.com.