Any where to find the doc for lc-each, lc-else and lc-for-c ?
Ronaldo wrote
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.
Afaik, "Backward compatibility" is always the major concern of OpenSCAD
development. Many developments would have been much easier if we didn't
insist on "Backward compatibility".
$ 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-tp18823p18907.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo wrote
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.
then we have ?: plus if/else plus filter, with filter only allowed
where? Within if/else branches?
Remember: The original problem is that ?: can't return a "nothing". So why
not solve this issue?
You must all admit, that it was not very thoughtful to introduce
if-without the way it was introduced. So beware of introducing even more
unclever things.
So, again: a null-value gives a lot of freedom and will solve the full
problem, while keeping up backward compatibility. /It is also fine to
restrict its scope to LC only/. It can, but does not have to be overloaded.
I gave only an example (which was misleading).
- allow a "value" null within LC only
- let if-without return a *null * when its predicate is false
- let ?: "transport" a *null * in both branches
- let LC eliminate any null
and we are done - without blowing up the language and /any inconsistencies/
extinguished.
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18908.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot wrote
So, again: a
null
-value gives a lot of freedom and will solve the full problem, while
keeping up backward compatibility.
/
It is also fine to restrict its scope to LC only
/
.
From a language standpoint "NULL" is ambiguous since it is also used as a
pointer to nothing. NULL is a conventional name for a zero pointer in C. In
Lisp, NULL is a test for the value NIL, which is synonymous with []. Python
introduced the "None" value and Algol68 used "void" -- later adopted by C++
-- both of which are less ambiguous. Void would be theoretically more
preferable, since it is used in C++ with exactly the same meaning, whereas
Python's None does carry a value. In practise though, None would probably
cause less confusion.
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18909.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot wrote
From a language standpoint "NULL" is ambiguous since it is also used as a
pointer to nothing. NULL is a conventional name for a zero pointer in C.
In Lisp, NULL is a test for the value NIL, which is synonymous with [].
Python introduced the "None" value and Algol68 used "void" -- later
adopted by C++ -- both of which are less ambiguous. Void would be
theoretically more preferable, since it is used in C++ with exactly the
same meaning, whereas Python's None does carry a value. In practise
though, None would probably cause less confusion.
Finding a good name for the baby is also important. You are right. NIL
(Not In List) would be a promising candidate.
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18910.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I really can't see why you prefer the cryptic ternary operator and a magic
null value to the if / else that is already implemented. It's more
readable, introduces no new keywords, and is similar to other languages.
On 3 November 2016 at 11:46, Parkinbot rudolf@parkinbot.com wrote:
Parkinbot wrote
From a language standpoint "NULL" is ambiguous since it is also used as a
pointer to nothing. NULL is a conventional name for a zero pointer in C.
In Lisp, NULL is a test for the value NIL, which is synonymous with [].
Python introduced the "None" value and Algol68 used "void" -- later
adopted by C++ -- both of which are less ambiguous. Void would be
theoretically more preferable, since it is used in C++ with exactly the
same meaning, whereas Python's None does carry a value. In practise
though, None would probably cause less confusion.
Finding a good name for the baby is also important. You are right. NIL
(Not In List) would be a promising candidate.
--
View this message in context: http://forum.openscad.org/Any-
where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18910.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
nophead wrote
I really can't see why you prefer the cryptic ternary operator and a magic
null value to the if / else that is already implemented.
Mainly because
- you can't get rid of ?:
- it is (very) bad language design to have two operators for the same thing
with only partial semantic equivalence. - there is a better solution
The null-approach solves all problems and is fully backward compatible.
Anyone can seemlessly continue to use if-without (now in any branch)
without even getting into contact with null. But one can also explicitly
use null in /both/ branches of ?:.
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18912.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
To make my position even clearer: With fixing the ?: + if-without issue,
if/else may be introduced as is, provided we then have semantic
equivalence.
Parkinbot wrote
The
null
-approach solves all problems and is fully backward compatible. Anyone can
seemlessly continue to use
if-without
(now in any branch) without even getting into contact with
null
. But one can also explicitly use
null
in
/
both
/
branches of
?:
.
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18913.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot wrote
To make my position even clearer: With fixing the
?:
if-without
issue,
if/else
may be introduced as is, provided we then have semantic equivalence.
Parkinbot wrote
The
null
-approach solves all problems and is fully backward compatible. Anyone
can seemlessly continue to use
if-without
(now in any branch) without even getting into contact with
null
. But one can also explicitly use
null
in
/
both
/
branches of
?:
.
It is not so simple. In your/runsun's proposal, we face two directions:
either only ?: is changed in the context of LC (and we cannot use use ?:
inside any expression anymore as it happens currently with if-without) or
all operators should deal with nil, null whatever. The former is a severe
restriction, the later a huge change. Particularly the later annoy me: in
the lack of documentation, I will have to guess or test each possible
occurrence of nil, null, whatever in LC expressions as I often do with
undef.
In my simple mind, ?: is an operator and can be used freely in any
expression with other operators. I don't see if-else or if-without as
operators but as a data flow control devices. Operators require all its
operands to work and data flow control devices cannot be wrapped in
expressions. So they are different things with different goals. We have both
?: and if/if-else in statement level (and in many other languages) and
people don't get confused with their use.
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18916.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
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?
The compiler will see whether a nil-value is evaluated in the LC-context
or not, just like if-without (or let within function context). The
question will be, whether we allow for a function to return nil. With *nil
*restricted to LC-context I wouldn't, otherwise *nil *can be handled like
undef.
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18917.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Man, I'm just look at this thread and smh.
The if inside of the LC context is a very specific case. This else
extension in the LC context is a nice to have from what I've seen in this
thread and while using just the lc-if feature as it can make things
clearer and easier to manage.
From what I can see, the lc-if and lc-else are only meant to be used at
the top level of any LC context, which includes lc-if, lc-else and
lc-each context and not anywhere else.
If there is no final lc-else in a lc-if/lc-else lc-if/... series, then
this still acts as a filter, with the ability to not generate an item. It
is only if the is a final lc-else, that this can be replaced by a ternary
sequence.
Please do not modify the ternary operator, that will just add more
complexity when it is not needed. Even if there was a lc-ternary-operator
created (which again, I do not advocate), it should be limited to only to
the top level of an LC context, or else a full analysis of using /null/
should be done when it generates a /null/ and interacts with other
operators, as was being said in terms of /1+null/, /1*null/, etc., which in
my mind should just generate an error, or maybe another /null/ like
/1+undef/ generates another /undef/. I'm very weary about this however, as
this can result in unnecessary evaluation and convoluted code.
--
View this message in context: http://forum.openscad.org/Any-where-to-find-the-doc-for-lc-each-lc-else-and-lc-for-c-tp18823p18918.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
