This would be different than the "if/else" + "if filter" combination, 'cos
it turns the entire construct into a filter, not the branch of it. But we
already have a filter: "[ for(...) if(a==v) a ] ", make no sense to invent
another one.

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

nophead wrote

Doesn't that fall into the same logic that we implement a behavior (i.e, can
use/each/ with /else/), then turn around to argue that it's the ground for
the implementation of behavior (/else/) ?

If we can make if/else accept each, what's there to prevent us from
implementing the same behavior like this ?

(a%2)?a: each a, a*a

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

Because it is totally alien to have the ternary operator being anything
other than part of an expression, not a control construct. And adding a
null expression that fails to produce a value is also weird.

On 1 November 2016 at 20:50, runsun runsun@gmail.com wrote:

runsun wrote

Well, the filter we have is not general enough. So if you "invent" one that
solves the problems being addessed in this thread, it is not just an another
one, but a better one. And this makes sense.

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

nophead wrote

For those who don't want to use if-else in LC, here is a substitute. Instead
of:

use the equivalent:

It is artificial, I know, but better than changing behaviors of well
established operators and constructs.

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

nophead wrote

When developers improve a language, they keeps adding "alien" things. For
example, when generator was invented (like, in python), it's totally alien.
The newest javascript ES6 incorporates many "alien" constructs, too.

In OpenSCAD, when we turned an "if(A){...}" into a functional style filter
in lc:

[ for(...) if(A) B ]

that's alien to me, too --- A branching "if" is turned into a functional,
lambda sort of filter that returns something immediately and drops something
else.

That is, anything new or improved would be "alien" or "weird" to some
people. So "alien" or "weird" shouldn't be a ground to reject something new.

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

You guys keep mentioning "A?B:C" being a "ternary operator" so it can't be
allowed to do stuff that "if-else" does.

You guys seem to forget that, when a "if-else" construct:

is used in the lc context:

it already switches its role from an expression that only do something to an
operator that returns something immediately.

That is, in a lc context, the role of "if(A)B else C" IS a ternary
operator just like "A?B:C".

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

Parkinbot wrote

I'm not quite sure which filter you said is not general enough.

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

Runsun said:

There's no essential difference between
if (x != 0) cube(x);
at the statement level, and
if (x != 0) f(x)
in a list constructor. The first adds a shape to the model if x!=0, and the
second adds a value to the list under construction if x!=0. At the
statement level, we are constructing a list of shapes to union together,
and in a list constructor, we are constructing a list of values. Remember
that OpenSCAD is a declarative language, so both of these are functional
constructs. And they are really the same functional construct.

The main problem I see with the "lc-else" extension is that it is now
possible to write [if (a%2==0) a else a10] in a list constructor, but you
can't write if (a%2==0) a else a10 as an expression. Once we extend
expressions to support the if-else construct, then this inconsistency will
go away, and we will have a single syntax for conditionals (if-else) that
works in statements, list constructors and expressions.

On 2 November 2016 at 12:01, runsun runsun@gmail.com wrote:

runsun wrote

The one implemented in the actual release 2015.03. There we have if and no
if/then (which is only available in the dev snapshots). This if can't be
used within the ternary ?: and thus is not general.

So, with respect to the next release, the filter could still be redesigned
properly e.g. by the proposed null value approach, avoiding the
introduction of if/then within expressions as well as a lot of confusion
and redundancy caused by it.

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