Any where to find the doc for lc-each, lc-else and lc-for-c ?
doug.moen wrote
Parkinbot wrote:
nested ?: ARE ugly.
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.
Just came in from the other thread, in which I just posted my solution to
complex "?:" :
function f(x)=
(
x==1?
let(...)
(
......
......
)
: x==2 ?
let(...)
(
......
......
)
: x
);
This is exactly like an "if-else", and we already have this for a long long
time, no idea why this is ugly.
$ 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-tp18823p18892.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot wrote
runsun wrote
I still think a [ for(...) a==A?a:if(a==B)C ] is more readable, though.
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.
As far as I can remember, I didn't advocate a nested "?:". I was just
saying, your solution of inventing a /null/ in a "?:" ( a==v?a:null)
provides a different result than that of our discussion target [ for(...)
a==A?a:if(a==B)C ], therefore is not a solution to our problem.
If you want to use that (a==v?a:null) as a solution to our issue, then you
have to use nested "?:" --- one "?:" one for branching, one "?:" for
filtering.
If this path is chose, then, basically, instead of changing the role of "if"
from a filter ("if" w/o else) to a branching construct ("if-else") and mix
them, it changes the role of "?:" from a branching construct to a filter
(A?B:null) and mix them. That is not a good thing and that's why I don't
like it.
Btw, ?: is ugly ONLY IF you make it so. See my previous post to doug.
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:
echo(10 + null); // 10 : interpreted by the +-operator as 0;
echo (10 * null); // 10 : interpreted by the *-operator as 1;
echo (10 % null); // 10 : interpreted by the %-operator as op1;
echo ([ a, null]); // [a] : interpreted by LC as element to omit or skip;
echo ([ a, [null]]); // [a, []]
echo (null); // null : like undef
echo (str("Hi", null)); // Hi : null is no character
and so on.
Agree.
$ 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-tp18823p18893.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot said:
Look at:
a = if (b) c;
Which value will a get, if b is false?
That should be a compile time error, complaining about the missing 'else'
keyword. (It is an error in my "OpenSCAD2" prototype.)
An if without an else only makes sense at the statement level, and inside a
list comprehension. In an expression, it should be an error, just as it is
an error to write
a = b ? c;
On 2 November 2016 at 20:23, Parkinbot rudolf@parkinbot.com 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:
a = if (b) c;
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.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
The guy who posted that thread was expecting to use if-else, and went to
the forum when he didn't find it. If we had an if-else expression, his
expectations would have been met, and he wouldn't have needed to ask on the
forum.
That's proof that our current syntax is confusing.
On 2 November 2016 at 20:25, runsun runsun@gmail.com wrote:
doug.moen wrote
Parkinbot wrote:
nested ?: ARE ugly.
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.
Just came in from the other thread, in which I just posted my solution to
complex "?:" :
function f(x)=
(
x==1?
let(...)
(
......
......
)
: x==2 ?
let(...)
(
......
......
)
: x
);
This is exactly like an "if-else", and we already have this for a long long
time, no idea why this is ugly.
$ 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-tp18823p18892.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
doug.moen wrote
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".
To clarify things, I raised my opposition against "if(A) if(B) C else D" in
the
lc context not because I am against using "if-else", but because the
confusion
of mixing "if-else" (a branching construct) and "if" (a filtering
construct) in
the lc. It means users have to face the confusion of which "if" the "else"
goes
with, and the confusion that "if" is sometimes a filter, sometimes a
branching.
If we:
- didn't have "if" as a filter to begin with, then I would support
"if-else" in the
lc or anywhere else; And advocate using another filter (for example,
"filter" or
"pick" or else) to go with this "if-else":
[ for(...) filter(C) D ]
[ for(...) if(A) B : filter(C) D ]
Then we don't have all the confusions and all the issues solved. But we
already
passed that point.
- don't allow "if"-filter to go with "if-else" in the lc, so there never
will be a
confusing code like "if(A) if(B) else C" (I believe this is gonna burn
many
brain cells and requires unnecessary brain twists even for people who
support mixing
"if" and "if-else"), then, again, I'll support "if-else" goes into the lc.
We are half-way passed this point now.
The point I want to make is: the problem is on the mixing use of "if" and
"if-else",
not "using if-else in the lc". So the argument of saying other language has
already
used "if-else" in the lc is somehow irrelevant here.
$ 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-tp18823p18899.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
doug.moen wrote
The guy who posted that thread was expecting to use if-else, and went to
the forum when he didn't find it. If we had an if-else expression, his
expectations would have been met, and he wouldn't have needed to ask on
the
forum.
uurrhhh... I was countering your comment of a nested "?:" being ugly and
showing you that it's only ugly if you want it to. If one chooses to write
the
code in a ugly way when it can be written beautifully, then I don't think
he/she
has the right to claim the code is ugly.
Besides, didn't that thread also show that the OpenSCAD is powerful enough
to
handle his problem without the need of wasting resources in something we
already
can do beautifully ?
$ 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-tp18823p18901.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
runsun wrote
- didn't have "if" as a filter to begin with, then I would support
"if-else" in the
lc or anywhere else; And advocate using another filter (for example,
"filter" or
"pick" or else) to go with this "if-else":
[ for(...) filter(C) D ]
[ for(...) if(A) B : filter(C) D ]
Then we don't have all the confusions and all the issues solved. But we
already
passed that point.
I agree with this suggestion. A filter called "filter" is clearer and solves
all confusions as far as I can see. To change the filter name from "if" to
"filter" is a matter of deprecating the first as was done with assign.
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18902.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Runsun:
To clarify things, I raised my opposition against "if(A) if(B) C else D" in
the lc context not because I am against using "if-else", but because the
confusion of mixing "if-else" (a branching construct) and "if" (a filtering
construct) in the lc. It means users have to face the confusion of which
"if" the "else" goes with, and the confusion that "if" is sometimes a
filter,
sometimes a branching.
Thanks for clarifying. However, the syntax you object to comes from C,
and is part of every C-like language, including OpenSCAD.
How is
if(A) if(B) C else D
in a LC any more objectionable than
if(A) if(B) C; else D;
at the statement level, something we've always supported?
The confusion that you're pointing at (which "if" the "else" goes with)
is called the dangling-else ambiguity. Some language designers avoid
it by not using the ambiguous C syntax, replacing it with an alternate
syntax which isn't ambiguous. Other languages (eg, Javascript and
OpenSCAD) use the C syntax, and the C rule that the else goes with
the inner-most matching if.
Developers typically use a coding convention to reduce or eliminate
the ambiguity. You can use indentation to make the code clearer:
if (A)
if (B) C else D
and/or you can use bracketing to remove the ambiguity
(braces in statement context, parentheses in LC context)
if (A) (if (B) C else D)
if (A) (
if (B) C else D
)
or this to force the other interpretation:
if (A) (if (B) C) else D
if (A) (
if (B) C
) else
D
As a C/C++ programmer, I alway use bracketing to eliminate ambiguity in my
own code, purely as a matter of coding style. And I do the same thing when
writing OpenSCAD code.
I figure that this isn't a big deal. We've been using the C if syntax since
the beginning, and it's a popular syntax, so why change things now?
On 2 November 2016 at 21:05, runsun runsun@gmail.com wrote:
doug.moen wrote
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".
To clarify things, I raised my opposition against "if(A) if(B) C else D" in
the
lc context not because I am against using "if-else", but because the
confusion
of mixing "if-else" (a branching construct) and "if" (a filtering
construct) in
the lc. It means users have to face the confusion of which "if" the "else"
goes
with, and the confusion that "if" is sometimes a filter, sometimes a
branching.
If we:
- didn't have "if" as a filter to begin with, then I would support
"if-else" in the
lc or anywhere else; And advocate using another filter (for example,
"filter" or
"pick" or else) to go with this "if-else":
[ for(...) filter(C) D ]
[ for(...) if(A) B : filter(C) D ]
Then we don't have all the confusions and all the issues solved. But we
already
passed that point.
- don't allow "if"-filter to go with "if-else" in the lc, so there never
will be a
confusing code like "if(A) if(B) else C" (I believe this is gonna burn
many
brain cells and requires unnecessary brain twists even for people who
support mixing
"if" and "if-else"), then, again, I'll support "if-else" goes into the lc.
We are half-way passed this point now.
The point I want to make is: the problem is on the mixing use of "if" and
"if-else",
not "using if-else in the lc". So the argument of saying other language has
already
used "if-else" in the lc is somehow irrelevant here.
$ 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-tp18823p18899.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
doug.moen wrote
the syntax you object to comes from C,
and is part of every C-like language, including OpenSCAD.
How is
if(A) if(B) C else D
in a LC any more objectionable than
if(A) if(B) C; else D;
at the statement level, something we've always supported?
You brought up both C-like languages and python to argue the legitimacy
of using "if-else" as a way completely the same as "?:" in OpenSCAD such
that we have both "if-else" and "?:" doing exactly the same thing.
But, as far as I know, python doesn't have "?:", and the c-like language
I know, javascript, doesn't have a "if-else" as a ternary operator in its
array construct or statement expression level.
Would any language designs a construct A because language X
has A, then design another construct B that serves exactly the same purpose,
because language Y has it ?
I don't think so, not to mention that X has only A and Y has only B, but now
we
are trying to catch them all. That's a waste of resources and a bad
direction
of development.
$ 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-tp18823p18905.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
In a previous post I said,
runsun wrote
- didn't have "if" as a filter to begin with, then I would support
"if-else" in the
lc or anywhere else
...... - don't allow "if"-filter to go with "if-else" in the lc.... I'll support
"if-else" goes into the lc.
After giving more thoughts, I retract my support of "if_else" usage in any
of the lc
context ( like [ for(...) if(A)B else C ] ) or on the statement expression
context
(like a= if(A)B else C) for a simple reason :
OpenSCAD can do it already with "?:"
In an earlier thread, nophead
http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18771.html
was arguing against a lambda function by saying:
nophead wrote
It also means OpenSCAD needs more maintenance as its code gets a bit
bigger and there needs to be a more test cases. Fine for indirect
functions because they add power but lambda doesn't. It is just a slight
shortcut that saves you thinking up a name. Unless some optimisation is
done it leads to code duplication because once a named function is written
it can be used multiple times."
I countered by saying that any NEW feature of a language will increase
maintenance burden so it shouldn't discourage us from adding new one.
But what we are discussing here in this thread is to repeat the same
functionality of a current construct with new construct that serves nothing
but ... well, I actually don't know .... so can't be considered a new
thing. So nophead's argument above provides indisputable ground for us to
drop this "if-else" stuff.
In other words, we are wasting out time now, and waste the time of our
future.
$ 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-tp18823p18906.html
Sent from the OpenSCAD mailing list archive at Nabble.com.