I grew up on Pascal and Modula-2. In those languages, TRUE/FALSE have
nothing to do with numbers: "IF (3)" is simply an error.  So to ME, all
of this is nonsense.

Which demonstrates how differently we all feel about these issues

On 7/26/2020 2:44 AM, Hans L wrote:

thehans wrote

wiki

So much code is based on that. Why change?

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/

Note that the change under discussion may have been made a while ago, but I,
at least, don't run the nightly builds because I'm doing library development
and the library is meant to run under the stable release.

In what way(s) is OpenSCAD not strongly typed?  Generally when I combine
types in an operation OpenSCAD returns undef.  This is why I suggested
OpenSCAD was strongly typed, since this is the OpenSCAD equivalent of
issuing an error.
In what way would you say that OpenSCAD is not strongly type?  I have come
up with one example of weak typing: the automatic casting of non-booleans to
booleans in a boolean context.  Are there any others?

test = [
"string",
[3],
33,
true];
result = [for(i=[0:1:3], j=[i+1:1:3]) test[i]+test[j]];
echo(result);

Testing for all types above, I get undef for every case.  In what way would
you say that OpenSCAD is not strongly type?  I have come up with one example
of weak typing: the automatic casting of non-booleans to booleans in a
boolean context.  Are there any others?

In fact, the various weak-type behaviors I'd like to see are all absent.
I'm talking about things like array+scalar, or comparisons like array<scalar
or array<array.  Note: I'm not requesting these things or saying we need
them.  I'm just saying they are weak type behaviors I'm used to from MATLAB
where OpenSCAD just returns undef--the strong type behavior.

The only operations that I can find that doesn't return undef or return an
appropriate multi-type result (e.g. matrix times scalar) are the relative
comparisons.  If you really want to make things consistent it still seems to
me that the best way to do that is to make relative operations return undef
for mismatched types.

I don't understand how this change would break code that is not also broken
by changing comparisons of booleans to return false.

Parkinbot, I don't understand what you mean.  Right now undef is treated as
false in a boolean context, and nobody is suggesting that this change.  So
someone who does comparisons like "if (true<3)" will get the
same result if such comparisons return false as if they return undef.  The
only difference would be if you store the result or explicitly check the
result like

(true<3) == undef

or

(true<3) == false

<quote author="Parkinbot">
thehans wrote

This is not an option for a boolean operation unless you identify "undef" as
"false" and get caught in the same pitfall. You could throw an error or at
least a warning, but this will break tons of legacy code.

I would opt for a clear and consistent implementation, which is neither
the new nor the old implementation.

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

OpenSCAD mailing list
Discuss@.openscad
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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

MichaelAtOz wrote

This doesn't relate to the current conversation about the behavior of
booleans in relative comparisons.  Nobody is suggesting that we change how
boolean contexts are handled, with the argument in such a context being cast
to a boolean following the above method.

The question at hand is what should happen when you use the <, >, <=, =>, or
== operators with booleans.  Is there tons of code based on using relative
comparisons between numbers and booleans?  What is the use of such a thing?
It doesn't make sense.  Only equality testing makes sense, and the whole
issue at hand is that the latest development breaks equality testing.

The wiki says this:

If both operands are Booleans, true > false. In an inequality comparison
between a Boolean and a number true is treated as 1 and false is treated as
0. Other inequality tests involving Booleans return false.

Dissimilar types always test as unequal with '==' and '!='. Inequality
comparisons between dissimilar types, except for Boolean and numbers as
noted above, always result in false.

So the question is what should be behavior be for inequality tests between
dissimilar types.  I'm suggesting that it should be to return undef, since
that is consistent with how other operations behave when you combine
dissimilar types.  And this should rarely break anything since undef casts
to false in a boolean context.  In other words, changing 3<[3] from false to
undef won't change code that uses this in a boolean context, since undef is
false in that context.  The only real change would be to code that relies on
comparing booleans to numbers because the change would mean that true<4
would return undef instead of true, and that would test as false.    But if
we went with the other notion of returning false for this test it has the
same impact on existing code.

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

On Sun, Jul 26, 2020 at 5:15 AM Parkinbot rudolf@digitaldocument.de wrote:

OK, but saying this alone is not helpful without explicitly defining what
consistent means to you.
So, would you be satisfied with what I proposed here (yes/no)? :

On Sun, Jul 26, 2020 at 1:44 AM Hans L thehans@gmail.com wrote:

On Sun, Jul 26, 2020 at 7:51 AM adrianv avm4@cornell.edu wrote:

I can certainly understand the desire to support stable releases for
libraries (i.e. not relying on experimental features).  But as a library
developer it seems to me you also have a vested interest in future
development of OpenSCAD.
So while you may prefer to develop for (and on) the stable release, I would
strongly encourage you and other library authors to, at least periodically,
test against nightlies.  This would really help identify any possible
breaking changes early on, before they become more permanently ingrained in
the next stable release.
OpenSCAD has a fairly comprehensive test suite which helps identify many
such regressions, but it's thoroughness is dependent on issues being raised
on Github with reproducible test cases etc.
Also, as a library author, I would assume you are more likely to make use
of esoteric / niche features of the language which more casual users may
not be aware of, which makes them even more valuable as test cases.

I don't care to dive deeply into semantic arguments here, since it seems
that strong typing means different things, with various qualifications and
exceptions, depending on who/what language you ask.
What I specifically said was "... I don't believe anyone has ever claimed
[OpenSCAD] to be [strongly typed]"  (with the exception of you, now).  This
means, to the best of my knowledge, none of the documentation nor project
authors have made this claim.
If you want to argue against that, then the burden of proof is on you to
show otherwise.  In fact googling for ( "strongly typed" OpenSCAD ) has a
first result of Doug Moen explicitly saying "OpenSCAD isn't designed to be
a strongly typed language".  I don't consider myself an expert on
programming linguistics by any means, but since Doug has previously put a
lot of thought and effort into the (unfortunately now defunct/abandoned I
guess) "OpenSCAD2" specification, I would defer to his knowledge on the
subject.  Doug has replied in this thread already, though not specifically
addressing whether or not (or to what degree) OpenSCAD may be considered
strongly typed, but I would be all ears if he cares to elaborate any.

OpenSCAD is perfectly capable of throwing errors and does so in many cases,
so I don't agree that returning undef is "equivalent" to issuing an error.
In the underlying implementation, undef is its own type, as is boolean,
and we don't use tri-state booleans.  The very nature of returning undef
sometimes and bool/number/vector etc at other times makes this not
particularly strong in my opinion.  The strongest response would be to stop
on error when two incompatible operands are used, but changing this
fundamental behavior would likely break a whole lot of things.

Comparison operators are currently implemented such that they
always return a boolean.  Returning undef would mean redefining all of
these operators to return the variant (sum type) of "Value", making them
weaker in that sense.
In cases where the result of comparison is not being used directly in the
context of a condition, say it's assigned to a variable or a vector
element, then returning undef only serves to further this muddling of types.

Treating booleans as numbers where zero means False and everything else
means True has served us well for decades in many programming laguages.

I understand the desire to treat booleans more special, but that doesn't
mean that I would support their behavior to become completely randomized or
non sensical. If you allow an expression of (one_bool EQ another_bool) and
the result isn't True if both are True or both are False, then you create a
huge footgun for no apparent reason whatsoever. Better make that throw an
error at compile time.

There is no real sense in having GT, LE and so on operators for booleans.
That should always throw an error early on. But equality and inequality
operators even exist in very well defined and designed language standards.
Being the oddball in this regard isn't going to serve us well.

Best Regards, Jan

On Sun, Jul 26, 2020 at 4:01 PM Hans L thehans@gmail.com wrote:

--
Jan Wieck
Principal Database Engineer

Since my name was mentioned, I better reply.

I understand "strongly typed" to mean that each function has a well defined contract, in terms of the types of arguments that it accepts, and that this contract is enforced either at compile time or run time. An error is reported if arguments have the wrong type. The goal is to stop the program from running and report a problem if function arguments appear to be garbage. The alternative being to keep running and produce garbage in the end, and you have no idea where the program went wrong.

The OpenSCAD2 project evolved into a brand new language called Curv, which is strongly typed, with dynamic types. For example, the boolean operators only accept the values true and false as arguments. If you pass non-boolean arguments, the program aborts with an error and a detailed stack trace. This is the way I wish OpenSCAD worked, because it makes programs easier to debug, so I created my own 3D modelling language that works this way.

For the most part, OpenSCAD functions silently return undef when passed bad arguments. For example, 1+true is undef. I don't consider this to be "strongly typed" behaviour. However, changing OpenSCAD to be strongly typed would break a lot of existing code, which would be undesirable.

Doug Moen.

On Sun, Jul 26, 2020, at 3:59 PM, Hans L wrote:

thehans wrote

I'm not sure if you were asking me or Parkinbot (who you quoted).
Ultimately I don't particularly care what relative comparison operators do
when given booleans.  It's a pointless combination that should never be
used.  If you return false for all cases that's fine with me.  I think
returning undef for all relative compares between different types is better
and more consistent across the language.  But ultimately, it doesn't matter.

What does matter is the behavior of equality testing, where I insist that
(x==true) is true only when x is the actual boolean true and not for any
other value.  And similarly (x==false) is true if and only if x is the
actual boolean value false.

Indeed, this situation has made clear the need for testing against the
development versions.  We're building up regression tests for the functions
in the library, which should make it possible to catch problems created by
changes in OpenSCAD---if we write our regression tests well.  We don't have
any mechanism to test geometry.

I would say that OpenSCAD may occasionally issue errors, but for most error
conditions it instead confounds the programmer by returning undef instead,
so that the error can propagate along ten functions more before finally
producing an obvious problem.  I've spent hours debugging code just
tracking down where errors occur because of this behavior, where an
immediate error would have directed me immediately to the problem.  This
has lead me to the philosophy that undef should never be intentionally
returned by any function.  It's kind of too bad since the notion of undef is
useful, e.g. for returning the intersection point of two parallel lines.
But it seems more important to do as much as possible to distinguish
meaningful returns from programming errors.

The change that prompted this discussion had to do with establishing
consistency.  I maintain that consistency is maximized if comparisons
between different types return undef, which is kind of the "no type" type.
I don't think it particularly muddles types---certainly not any more than
the standard where x+y can be undef.  It sounds like this is an annoying
change in the code.  I don't really see that this consistency has much
practical value and would not want programmers to spend their time on this.
Returning false for all inter-type comparisons is reasonably consistent as
well.

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

adrianv wrote

I think, I was very clear in what I wrote and what I am opting for:
1: Apples are no pears -> if operands have different types, "false" results
2: tertium non datur -> a boolean operation returns a boolean value, i.e.
"true" or "false" but nothing else.

identifying "undef" and "false" and allowing "undef" as result of an
apples/pears comparison would introduce a third value and thus allow for
implicit type checks, not more and not less. But with the new is_XXX()
functions we have means to do explicit type checks, why introduce/support
implicit ones?

if(undef != (op1 == op2))  // this would be a generic type check, if undef
is introduced

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