What happened to booleans?

classic Classic list List threaded Threaded
83 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

Parkinbot
However, with an implementation that follows rules 1 and 2 of my previous
post, you still can do such a generic type check by writing:

function is_same_type(op1, o2) = (op1==op2)!=(op1!=op2);



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

Parkinbot
Another issue of allowing "undef" as result of a logical operation:

What is the value of

(false == undef)?

It obviously can't be "true", otherwise you could not distinguish between
these two values, and if it is "false" you get the following contradiction.
The expression
 
(1 == "1") == false

would evaluate to

undef == false

and this evalulates to false (or undef?). However "true" is expected.
This is all a can of worms.





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

MathLover
If I may add something to the discussion, I would really like booleans to be
booleans. Also, I LIKE error messages if I am doing something that just does
not make sense. As someone once said, the language should talk to you
(meaning the language gives useful error messages rather than assume
nonsense and do unexpected things).

So if I would compare a boolean with greater or lesser operators, I expect
an error message. True is not more or less than false.

Microsoft languages like Visual Basic used to have a "feature" called "Null
progagation". This meant that if you used a Null value (which would also be
undef) anywhere in an expression, the outcome of that expression would also
be Null. This off course broke all boolean operations, because Null would be
treated as false.

Yes, ("Some value" != null) would thus be treated as false and even (! null)
would be treated the same as null, as false.

This made programming visual basic and other languages that had this
"feature" a minefield when dealing with booleans. So please don't go that
route. I have been there, and I really do not want to go back.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

adrianv
In reply to this post by Parkinbot
Parkinbot wrote

> Another issue of allowing "undef" as result of a logical operation:
>
> What is the value of
>
> (false == undef)?
>
> It obviously can't be "true", otherwise you could not distinguish between
> these two values, and if it is "false" you get the following
> contradiction.
> The expression
>  
> (1 == "1") == false
>
> would evaluate to
>
> undef == false
>
> and this evalulates to false (or undef?). However "true" is expected.
> This is all a can of worms.

I am not sure what gave you the idea that equality or inequality testing
should result in undef under any circumstances.  That would be very bad.  
Equality testing is well-defined for any pair of objects, they are either
the same (in which case you return true) or they are different (in which
case you return false).  Things with different types are clearly different.  

Inequality tests are different.  They are undefined (meaningless) when given
arguments of different type.   Hence my proposal was simply that inequality
tests (<, >, <=, =>) result in undef when given mismatched types.   I'd say
printing an error message would be even better.  



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

adrianv
In reply to this post by MathLover
MathLover wrote

> Microsoft languages like Visual Basic used to have a "feature" called
> "Null
> progagation". This meant that if you used a Null value (which would also
> be
> undef) anywhere in an expression, the outcome of that expression would
> also
> be Null. This off course broke all boolean operations, because Null would
> be
> treated as false.
>
> Yes, ("Some value" != null) would thus be treated as false and even (!
> null)
> would be treated the same as null, as false.
>
> This made programming visual basic and other languages that had this
> "feature" a minefield when dealing with booleans. So please don't go that
> route. I have been there, and I really do not want to go back.

OpenSCAD already has this feature with undef.  And yes indeed, it makes
debugging a nightmare.  

Right now any invalid operation---except for a boolean comparison---returns
undef.  And any operation containing an undef---except for equality and
inequality testing---produces an undef as a result.  

Index out of bounds?  You get undef instead of an error.   It would be a
thousand times better if all of these things produced immediate error
messages.  

So yes, it would make sense for boolean operations on mismatched types to
produce an error message.  The reason I didn't suggest that as a possibility
is consistency:  all the other bogus operations in OpenSCAD produce undef
instead of an error.  




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

mondo
In reply to this post by MathLover
Perhaps the solution is to have two types of boolean - a true boolean,
and a false boolean. The true boolean only has two members, true and
false, a false boolean can have as many members as you wish, but you
define them, and their relationship to each other. A true boolean can
only have too operators '==' and '!=', a false boolean can have whatever
operators you want. , but you'll need to define your own hierarchy.
Basically, in this scenario, a false boolean is everything else, which
may be further divided into strings, floating point numbers, colours,
whatever.

Historically, There has been a lot of misunderstanding about the true
nature of boolean, by folk who should have known better. Just because
digital computers work the way they do, they bypassed they forgot about
what the ones and zeros truly represented, and manipulated them in the
ways that ones and zeros would be manipulated as normal
bits/bytes/whatever. I blame their parents.

I guess the real concern is that openscad programs are interpreted, not
compiled, so older programs would not work properly in a newer
interpreter. Perhaps an interpreter version number could be included in
the data. (sort of like Microsoft .net asks for versions, but that is
hopefully backwards compatible). Whatever is decided, not everybody will
be happy, but at least we're trying.

Best wishes,

Ray


On 27/07/2020 12:41, MathLover wrote:

> If I may add something to the discussion, I would really like booleans to be
> booleans. Also, I LIKE error messages if I am doing something that just does
> not make sense. As someone once said, the language should talk to you
> (meaning the language gives useful error messages rather than assume
> nonsense and do unexpected things).
>
> So if I would compare a boolean with greater or lesser operators, I expect
> an error message. True is not more or less than false.
>
> Microsoft languages like Visual Basic used to have a "feature" called "Null
> progagation". This meant that if you used a Null value (which would also be
> undef) anywhere in an expression, the outcome of that expression would also
> be Null. This off course broke all boolean operations, because Null would be
> treated as false.
>
> Yes, ("Some value" != null) would thus be treated as false and even (! null)
> would be treated the same as null, as false.
>
> This made programming visual basic and other languages that had this
> "feature" a minefield when dealing with booleans. So please don't go that
> route. I have been there, and I really do not want to go back.
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

Ronaldo
In reply to this post by adrianv
'undef' is a nightmare indeed. But it is not the only one: there are 'nan' and 'inf' too which can turn into undef in the next operation. Should they be eradicated? Certainly not, they have their place, at least 'undef' has. To avoid nightmares, to have peace of mind, we need discipline. And consistent emergence of these values in operations.

What should be the result of a polygon triangulation function if the polygon has self-intersection? I would say that 'undef' (meaning "no solution possible") is the best option. To generate an error or an empty list (or some other signaling value) could be an alternative. The first seems radical because it is so hard to find  whether a polygon has self-intersection as trying to triangulate it. The triangulation function would be the check! The other options are falsely safe because a careless coder may get in trouble later trying to access an element of an empty list, for instance. There is no way to protect a careless code.That means we need to always be careful with operations that might have "unusual" results. That is a place for 'undef'.

Definitely an inequality expression involving pears and apples should result in 'undef' (as we don't have a complete type order). That is consistent with the result of trying to divide pears by a number or access an array component of a single value (and that doesn't mean 'undef' is another number value or another list) (*). But, yes, a test, either in an if() or in a ternary expression, of  'undef' should be an error. If you don't generate the error, the propagation will be uncontrollable. That is the devil's place. 'undef' should not be taken as 'false'. Why not allow the 'undef' value of an inequality be set to a variable? Or checked against 'undef' ? 'undef' is 'undef'.

(*) Dividing or multiplying a numerical vector by a scalar is a well defined operation on linear algebra. There are good well defined exceptions to the rule that 'pears' can't mix with 'apples'. 


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

nophead
If testing undef was an error it would break a lot of my code.

I often use if(list[n]) to mean if the list has a non zero nth element. If the list doesn't have that element I get undef, which is false. I would have to guard the test with a check of the length, which is less efficient and more verbose.


On Mon, 27 Jul 2020 at 15:37, Ronaldo Persiano <[hidden email]> wrote:
'undef' is a nightmare indeed. But it is not the only one: there are 'nan' and 'inf' too which can turn into undef in the next operation. Should they be eradicated? Certainly not, they have their place, at least 'undef' has. To avoid nightmares, to have peace of mind, we need discipline. And consistent emergence of these values in operations.

What should be the result of a polygon triangulation function if the polygon has self-intersection? I would say that 'undef' (meaning "no solution possible") is the best option. To generate an error or an empty list (or some other signaling value) could be an alternative. The first seems radical because it is so hard to find  whether a polygon has self-intersection as trying to triangulate it. The triangulation function would be the check! The other options are falsely safe because a careless coder may get in trouble later trying to access an element of an empty list, for instance. There is no way to protect a careless code.That means we need to always be careful with operations that might have "unusual" results. That is a place for 'undef'.

Definitely an inequality expression involving pears and apples should result in 'undef' (as we don't have a complete type order). That is consistent with the result of trying to divide pears by a number or access an array component of a single value (and that doesn't mean 'undef' is another number value or another list) (*). But, yes, a test, either in an if() or in a ternary expression, of  'undef' should be an error. If you don't generate the error, the propagation will be uncontrollable. That is the devil's place. 'undef' should not be taken as 'false'. Why not allow the 'undef' value of an inequality be set to a variable? Or checked against 'undef' ? 'undef' is 'undef'.

(*) Dividing or multiplying a numerical vector by a scalar is a well defined operation on linear algebra. There are good well defined exceptions to the rule that 'pears' can't mix with 'apples'. 

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

adrianv
In reply to this post by Ronaldo
I agree that undef is a useful concept and would be great if OpenSCAD
operated with it differently.  

What should happen is that any operation involving an undef is an immediate
fatal error, producing an error message---with the exception of the two
tests x==undef and x!=undef.   If OpenSCAD worked like this, then I would
feel comfortable using undef to report a variety of results where
"undefined" is actually the right answer, such as the previously mentioned
intersection point of parallel lines, or the example below of
self-intersecting polygons.  

Instead undef is actually the generic signal that the programmer made a
mistake.  In this case, I feel it is essential to avoid ever intentionally
producing undef because then you can't distinguish between an error and a
case of valid return.  Suppose your triangulation code has a bug and
sometimes returns undef as a result of this bug.  You can't distinguish that
situation from the case that the triangulation identified a
self-intersection.  If errors produced an error message and program halt
then a mistake in your code is easily distinguished from the undef return,
which happens in the self-intersecting polygon case.   But since errors
produce undef, it is critical that in any code, one tries to handle all the
errors and never produce undef intentionally as an output.  In this way we
know that if we see undef, there's a programming bug.  Otherwise, we can't
distinguish the case of a programming bug from a valid "undefined" return
value.  


Ronaldo wrote

> 'undef' is a nightmare indeed. But it is not the only one: there are 'nan'
> and 'inf' too which can turn into undef in the next operation. Should they
> be eradicated? Certainly not, they have their place, at least 'undef' has.
> To avoid nightmares, to have peace of mind, we need discipline. And
> consistent emergence of these values in operations.
>
> What should be the result of a polygon triangulation function if the
> polygon has self-intersection? I would say that 'undef' (meaning "no
> solution possible") is the best option. To generate an error or an empty
> list (or some other signaling value) could be an alternative. The first
> seems radical because it is so hard to find  whether a polygon has
> self-intersection as trying to triangulate it. The triangulation function
> would be the check! The other options are falsely safe because a careless
> coder may get in trouble later trying to access an element of an empty
> list, for instance. There is no way to protect a careless code.That means
> we need to always be careful with operations that might have "unusual"
> results. That is a place for 'undef'.
>
> Definitely an inequality expression involving pears and apples should
> result in 'undef' (as we don't have a complete type order). That is
> consistent with the result of trying to divide pears by a number or access
> an array component of a single value (and that doesn't mean 'undef' is
> another number value or another list) (*). But, yes, a test, either in an
> if() or in a ternary expression, of  'undef' should be an error. If you
> don't generate the error, the propagation will be uncontrollable. That is
> the devil's place. 'undef' should not be taken as 'false'. Why not allow
> the 'undef' value of an inequality be set to a variable? Or checked
> against
> 'undef' ? *'undef' is 'undef'*.





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

adrianv
In reply to this post by nophead
The efficiency argument is weak in this case.  I tested the run time for

len(foo) >=1001 ? foo[1000] : -1

compared to

foo[1000] ? foo[1000] : -1

where foo had length smaller than 1001.  

I ran this 10 millions times.  The run time for the length check was 1
microsecond.  The undef test shaved this down to 0.7 microseconds.  

I cannot conceive of a way that a different of 0.3 microseconds is important
in an OpenSCAD program.  

The problem of your code being broken is the serious one.  Personally if I
had a body of code written that way and the option to change OpenSCAD to
produce errors with undef I'd jump for errors in a heartbeat.  The amount of
time it would take me to fix a megabyte of code would be less than the time
I've wasted already debugging undefs that propagate through my code.   But
the backward compatibility problem is a definite problem.   Perhaps a
setting could be introduced to optionally make undefs into fatal errors,
similar to the setting that makes warnings into fatal errors.  


nophead wrote
> If testing undef was an error it would break a lot of my code.
>
> I often use if(list[n]) to mean if the list has a non zero nth element. If
> the list doesn't have that element I get undef, which is false. I would
> have to guard the test with a check of the length, which is less efficient
> and more verbose.
>
>
> On Mon, 27 Jul 2020 at 15:37, Ronaldo Persiano &lt;

> rcmpersiano@

> &gt;
> wrote:
>
>> 'undef' is a nightmare indeed. But it is not the only one: there are
>> 'nan'
>> and 'inf' too which can turn into undef in the next operation. Should
>> they
>> be eradicated? Certainly not, they have their place, at least 'undef'
>> has.
>> To avoid nightmares, to have peace of mind, we need discipline. And
>> consistent emergence of these values in operations.
>>
>> What should be the result of a polygon triangulation function if the
>> polygon has self-intersection? I would say that 'undef' (meaning "no
>> solution possible") is the best option. To generate an error or an empty
>> list (or some other signaling value) could be an alternative. The first
>> seems radical because it is so hard to find  whether a polygon has
>> self-intersection as trying to triangulate it. The triangulation function
>> would be the check! The other options are falsely safe because a careless
>> coder may get in trouble later trying to access an element of an empty
>> list, for instance. There is no way to protect a careless code.That means
>> we need to always be careful with operations that might have "unusual"
>> results. That is a place for 'undef'.
>>
>> Definitely an inequality expression involving pears and apples should
>> result in 'undef' (as we don't have a complete type order). That is
>> consistent with the result of trying to divide pears by a number or
>> access
>> an array component of a single value (and that doesn't mean 'undef' is
>> another number value or another list) (*). But, yes, a test, either in an
>> if() or in a ternary expression, of  'undef' should be an error. If you
>> don't generate the error, the propagation will be uncontrollable. That is
>> the devil's place. 'undef' should not be taken as 'false'. Why not allow
>> the 'undef' value of an inequality be set to a variable? Or checked
>> against
>> 'undef' ? *'undef' is 'undef'*.
>>
>> (*) Dividing or multiplying a numerical vector by a scalar is a well
>> defined operation on linear algebra. There are good well defined
>> exceptions to the rule that 'pears' can't mix with 'apples'.
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

Ronaldo
The amount of
time it would take me to fix a megabyte of code would be less than the time
I've wasted already debugging undefs that propagate through my code.   But
the backward compatibility problem is a definite problem.   Perhaps a
setting could be introduced to optionally make undefs into fatal errors,
similar to the setting that makes warnings into fatal errors.   

That already came to my mind. An alternative is to have a global variable, like $safe_mode, that would control the system reaction to an 'undef' result: no errors would be generated iff it is false, its default value. It could be set locally if needed.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

JordanBrown
In reply to this post by MathLover
On 7/27/2020 4:41 AM, MathLover wrote:
So if I would compare a boolean with greater or lesser operators, I expect
an error message. True is not more or less than false.

Sorting by a boolean makes sense, and the straightforward ways to sort want to have a greater/less concept.  Does that matter for OpenSCAD?  Don't know.

[null propagation] made programming visual basic and other languages that had this
"feature" a minefield when dealing with booleans. So please don't go that
route. I have been there, and I really do not want to go back.

Yeah... many years ago I implemented a similar concept in dBASE III.  I was adding date support, and it was clear that we needed blank dates, which in turn meant we had to define how comparisons worked on blank dates.  My answer was to move to ternary logic, so that the result of a comparison could be yes, no, or maybe.  It ... did not turn out well.  It made working with blank dates difficult, and had no redeeming value.

For those familiar with dBASE III and this issue... sorry about that.

I come up with four basic options for how to do mixed-type comparisons:
  • Coerce them to match.  Convert everything to strings, or to numbers, or some other scheme.  "1" == 1; "true" == true.
  • Mixed types are different values and so are never equal.  (You could define an ordering of the types, so that greater and less are defined and mixed-type lists are sortable.)
  • Mixed-type comparisons yield undef.
  • Mixed-type comparisons are errors.

Several languages (e.g. JavaScript) use the coercion. scheme.  C is partially coercion, for numeric types and maybe a few other cases, and errors for other.

I don't think the undef scheme offers any value.  It's basically saying that it's an error, without making the error be immediately visible.  I don't immediately come up with any value to it.

I'm not a big fan of coercion.  It provides opportunities for errors to go undetected, while providing little value.

That leaves "error" and "never equal".

"Never equal" is appealing.  It is "correct", in a sense, and allows for sortability.  On the other hand, it allows errors to go undetected.  On the whole, I think the cost (undetected errors) exceeds the value (sortability).

I guess that leaves me with a preferred answer of "error".

Special note:  undef should get special attention.  Comparing against undef should always be acceptable, and should yield true if both values are undef and false otherwise.


Now, note that that's all about comparison operators.  Boolean operators and contexts (e.g. "if") are a different question.  I'm OK with either being strict (require boolean values) or loose (define what "truth" means for each type individually).  If I was to start from zero, I'd probably define undef and false itself as false and all other values as true.  That would let you easily say "if the value is present, then..." and that seems more useful than having an easy way to test for zero and the empty string.  (And I'm obsessive and think the empty string is a perfectly good string, and that an empty list is not the same thing as no list at all.)  But we're not starting from zero; OpenSCAD uses a true/not-empty/non-zero style of truth and, shrug, that's OK.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

JordanBrown
In reply to this post by mondo
On 7/27/2020 6:23 AM, Ray West wrote:
Historically, There has been a lot of misunderstanding about the true nature of boolean, by folk who should have known better. Just because digital computers work the way they do, they bypassed they forgot about what the ones and zeros truly represented, and manipulated them in the ways that ones and zeros would be manipulated as normal bits/bytes/whatever. I blame their parents.

A lot of that comes from C, and it's important to remember that C is just a small step up from assembly language.  (The ++ and -- features, for instance, came directly from PDP-11 autoincrement and autodecrement instructions.)


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

JordanBrown
In reply to this post by Ronaldo
On 7/27/2020 9:08 AM, Ronaldo Persiano wrote:
That already came to my mind. An alternative is to have a global variable, like $safe_mode, that would control the system reaction to an 'undef' result: no errors would be generated iff it is false, its default value. It could be set locally if needed.

$something would have the wrong scope.  You want lexical scoping.

You want a file, module, or function to say "I want/don't-want safe mode" without having that affect other unrelated files, modules, or functions that it might call.  You want to let a library say, one time at the top, "I want safe mode".

But which is "safe", generating errors (and thus protecting you from bugs) or not (and thus "protecting" you from errors)?

Suggest something with a more definitive meaning, e.g. "allow_mixed_type_comparisons".


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

adrianv
JordanBrown wrote
>
> But which is "safe", generating errors (and thus protecting you from
> bugs) or not (and thus "protecting" you from errors)?
>
> Suggest something with a more definitive meaning, e.g.
> "allow_mixed_type_comparisons".

Who cares about mixed type comparisons???  Does anybody ever use them?  If
we banned them outright would anybody's code break?  Anybody have an example
of a use for a mixed type comparison?  

The topic has drifted to the broader topic of undef in general.  I suggested
mixed type comparisons should return undef because that would be consistent
(and the whole issue seemed to be a case of worrying a lot about
consistency).   But this leads to the question of undef in general, which is
a real problem that arises all the time.  And that's what Ronaldo was
talking about.  Perhaps "$return_undefs" would be a better name?  

It does seem like the scoping is bit of a problem, but the simple solution
is that any (library) code that relies on computations with undefs would
need to explicitly set the variable to true anywhere that it mattered.  This
seems kind of messy to me.  Also there is no precedent for this type of
control variable in OpenSCAD.  

It seems to me that if there's an interest in making OpenSCAD more usable it
makes more sense to make more of a break.  Introduce a new version where
errors are errors, similar to some of the breaking changes made in 2019.05.
If you need to run old code, you run it in compatibility mode where your
whole program runs in the old way, similar to how you can change the setting
to make warnings into fatal errors.   New code will still run in
compatibility mode.  You can just work entirely in compatibility mode if
undefs don't bother you.  This approach is straight forward and doesn't lead
to some complicated mess of people running code where parts of it need a
different mode than other parts.  It also directly deprecates the old style
and encourages better coding practice moving forward.

Another option would be to make operations on undef issue a warning.  Then
old code will still run, but if you want to you can enable the option that
makes warnings into errors.  




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

acwest
As was mentioned by somebody, mixed type comparisons for equality are well defined, so undef isn't really necessary for that. 

On Mon, 27 Jul 2020, 13:22 adrianv, <[hidden email]> wrote:
JordanBrown wrote
>
> But which is "safe", generating errors (and thus protecting you from
> bugs) or not (and thus "protecting" you from errors)?
>
> Suggest something with a more definitive meaning, e.g.
> "allow_mixed_type_comparisons".

Who cares about mixed type comparisons???  Does anybody ever use them?  If
we banned them outright would anybody's code break?  Anybody have an example
of a use for a mixed type comparison? 

The topic has drifted to the broader topic of undef in general.  I suggested
mixed type comparisons should return undef because that would be consistent
(and the whole issue seemed to be a case of worrying a lot about
consistency).   But this leads to the question of undef in general, which is
a real problem that arises all the time.  And that's what Ronaldo was
talking about.  Perhaps "$return_undefs" would be a better name? 

It does seem like the scoping is bit of a problem, but the simple solution
is that any (library) code that relies on computations with undefs would
need to explicitly set the variable to true anywhere that it mattered.  This
seems kind of messy to me.  Also there is no precedent for this type of
control variable in OpenSCAD. 

It seems to me that if there's an interest in making OpenSCAD more usable it
makes more sense to make more of a break.  Introduce a new version where
errors are errors, similar to some of the breaking changes made in 2019.05.
If you need to run old code, you run it in compatibility mode where your
whole program runs in the old way, similar to how you can change the setting
to make warnings into fatal errors.   New code will still run in
compatibility mode.  You can just work entirely in compatibility mode if
undefs don't bother you.  This approach is straight forward and doesn't lead
to some complicated mess of people running code where parts of it need a
different mode than other parts.  It also directly deprecates the old style
and encourages better coding practice moving forward.

Another option would be to make operations on undef issue a warning.  Then
old code will still run, but if you want to you can enable the option that
makes warnings into errors. 




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

adrianv
That we me, actually.  I wasn't clear in my last post when I was talking
about comparisons.  I meant relative comparisons: <, >, <= and =>.  These
are not meaningful between different types (and not necessarily even for
matched types).  

And just to be clear, the kinds of operations I'm talking about that produce
undef and frustrate debugging:

list[val] where val>=len(list) or val<0
x[val] where x is not a list
x+y where x and y are different types (including the case that either
argument is undef)
x*y where x and y are incompatible

and so on.  All of these things should be errors.


acwest wrote
> As was mentioned by somebody, mixed type comparisons for equality are well
> defined, so undef isn't really necessary for that.
>
> On Mon, 27 Jul 2020, 13:22 adrianv, &lt;

> avm4@

> &gt; wrote:
>
>> JordanBrown wrote
>> >
>> > But which is "safe", generating errors (and thus protecting you from
>> > bugs) or not (and thus "protecting" you from errors)?
>> >
>> > Suggest something with a more definitive meaning, e.g.
>> > "allow_mixed_type_comparisons".
>>
>> Who cares about mixed type comparisons???  Does anybody ever use them?
>> If
>> we banned them outright would anybody's code break?  Anybody have an
>> example
>> of a use for a mixed type comparison?
>>
>> The topic has drifted to the broader topic of undef in general.  I
>> suggested
>> mixed type comparisons should return undef because that would be
>> consistent
>> (and the whole issue seemed to be a case of worrying a lot about
>> consistency).   But this leads to the question of undef in general, which
>> is
>> a real problem that arises all the time.  And that's what Ronaldo was
>> talking about.  Perhaps "$return_undefs" would be a better name?
>>
>> It does seem like the scoping is bit of a problem, but the simple
>> solution
>> is that any (library) code that relies on computations with undefs would
>> need to explicitly set the variable to true anywhere that it mattered.
>> This
>> seems kind of messy to me.  Also there is no precedent for this type of
>> control variable in OpenSCAD.
>>
>> It seems to me that if there's an interest in making OpenSCAD more usable
>> it
>> makes more sense to make more of a break.  Introduce a new version where
>> errors are errors, similar to some of the breaking changes made in
>> 2019.05.
>> If you need to run old code, you run it in compatibility mode where your
>> whole program runs in the old way, similar to how you can change the
>> setting
>> to make warnings into fatal errors.   New code will still run in
>> compatibility mode.  You can just work entirely in compatibility mode if
>> undefs don't bother you.  This approach is straight forward and doesn't
>> lead
>> to some complicated mess of people running code where parts of it need a
>> different mode than other parts.  It also directly deprecates the old
>> style
>> and encourages better coding practice moving forward.
>>
>> Another option would be to make operations on undef issue a warning.
>> Then
>> old code will still run, but if you want to you can enable the option
>> that
>> makes warnings into errors.
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

MichaelAtOz
Administrator
In reply to this post by adrianv
The current undef behaviour allows you to handle errors.
You can detect that the result is undef and take appropriate action.
This is particularly useful when you don't have predefined data, or optional
parameters.

undef causing an error would prevent that, even a warning, it is already
problematic with warnings in for() loops or recursive code flooding the
console.

-------------------------------

Loaded design 'C:/Users/MeB/Documents/3D-REPRAP/Things/My
Things/badge.scad'.
Parsing design (AST generation)...
WARNING: Letter_height was assigned on line 7 but was overwritten on line 78
WARNING: kh was assigned on line 8 but was overwritten on line 128
Compiling design (CSG Tree generation)...
ECHO: "OS V=20190500"
ECHO: "OSLIB/Write/write.scad"
WARNING: search term not found: "B", in file badge.scad, line 93
WARNING: search term not found: "l", in file badge.scad, line 93
WARNING: search term not found: "a", in file badge.scad, line 93
WARNING: search term not found: "c", in file badge.scad, line 93
WARNING: search term not found: "k", in file badge.scad, line 93
WARNING: search term not found: "o", in file badge.scad, line 93
WARNING: search term not found: "s", in file badge.scad, line 93
WARNING: search term not found: "e", in file badge.scad, line 93
Compiling design (CSG Products generation)...
Geometries in cache: 129
Geometry cache size in bytes: 852176
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 1650000
Compiling design (CSG Products normalization)...
Compiling background (1 CSG Trees)...
Normalized CSG tree has 93 elements
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 23 seconds

-----------------------------

The first two are valid overwrites to overcome a include<> default
assignment.
The using search to not find something is perfectly valid logic, just lucky
in this case the text is short.



-----
Admin - email* me if you need anything,  or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

nophead
Overwriting a value from an include should not generate a warning. You should only get them if you assign twice in the same file and it looks like that is what you have.

I do find with new versions of OpenSCAD I have to add more code to get rid of warnings. It used to be OK to have zero or negative dimensions for primitives, they just disappeared, now I have to guard then with ifs.

It used to be OK to pass a scalar to len() and was documented to return undef, now it gives a warning and I have to guard it with is_list() and make my code not compatible with older versions.

There is current PR to make accesses off the end of a list a warning, so I would have to guard all my if(list[n]) statements because I have variable length object descriptions.

Perhaps I am just lazy but I like brief languages and it doesn't seem like progress to have to add more and more code to do the same thing.

On Tue, 28 Jul 2020 at 09:32, MichaelAtOz <[hidden email]> wrote:
The current undef behaviour allows you to handle errors.
You can detect that the result is undef and take appropriate action.
This is particularly useful when you don't have predefined data, or optional
parameters.

undef causing an error would prevent that, even a warning, it is already
problematic with warnings in for() loops or recursive code flooding the
console.

-------------------------------

Loaded design 'C:/Users/MeB/Documents/3D-REPRAP/Things/My
Things/badge.scad'.
Parsing design (AST generation)...
WARNING: Letter_height was assigned on line 7 but was overwritten on line 78
WARNING: kh was assigned on line 8 but was overwritten on line 128
Compiling design (CSG Tree generation)...
ECHO: "OS V=20190500"
ECHO: "OSLIB/Write/write.scad"
WARNING: search term not found: "B", in file badge.scad, line 93
WARNING: search term not found: "l", in file badge.scad, line 93
WARNING: search term not found: "a", in file badge.scad, line 93
WARNING: search term not found: "c", in file badge.scad, line 93
WARNING: search term not found: "k", in file badge.scad, line 93
WARNING: search term not found: "o", in file badge.scad, line 93
WARNING: search term not found: "s", in file badge.scad, line 93
WARNING: search term not found: "e", in file badge.scad, line 93
Compiling design (CSG Products generation)...
Geometries in cache: 129
Geometry cache size in bytes: 852176
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 1650000
Compiling design (CSG Products normalization)...
Compiling background (1 CSG Trees)...
Normalized CSG tree has 93 elements
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 23 seconds

-----------------------------

The first two are valid overwrites to overcome a include<> default
assignment.
The using search to not find something is perfectly valid logic, just lucky
in this case the text is short.



-----
Admin - email* me if you need anything,  or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: What happened to booleans?

MichaelAtOz
Administrator
nophead wrote
> Overwriting a value from an include should not generate a warning. You
> should only get them if you assign twice in the same file and it looks
> like
> that is what you have.

If I want to overwrite the default var 't' which is set in the include<>.
with an expression in the main program, such as
t=Letter_height+kh-0.1;
then Letter_height & kh must be in scope before the include<>, hence they
need to be assigned.
But they are assigned real values after the include<> in the main body of a
customizer, after the user selects a value.



-----
Admin - email* me if you need anything,  or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.
12345