[DGD]1.1.52

[Felix A. Croes]

Mikael Lind <z94lind at mtek.chalmers.se> wrote:

>[...]
> This is my current situation: When I code LPC, logical expressions don't
> evaluate to true or false, but rather to integer 1 or 0. I don't think of
> conditionals as requiring a boolean value, because they really don't. For
> instance, a construction such as
>
>     if (string_value) {
>         print(string_value + "\n");
>     }
>
> is logically hairy but practically useful. I use it all of the time. But I
> don't like it. There is of course the elegant alternative
>
>     if (string_value != nil) {
>         print(string_value + "\n");
>     }
>
> I could use this, but I don't want to. Since the interpretations of 
> the tests are identical, I prefer the shorter form. This is something that
> may or may not make sense to you. 

Before there was such a thing as nil in LPC, I've done the same thing,
mostly because all I could compare to was 0, and

    if (string_value != 0) ...

doesn't make sense.

I don't see why this is "logically hairly", though.  While it makes
sense to think in terms of boolean values, there is no requirement
to do so.  Evaluating the truth value of an expression can be
described in a logically consistent way.

As for errors caught at compile time with the addition of a boolean
type, the only plausible one that I can think of is

    if (foo = bar) ...

which has an integer value rather than a boolean value.  While I
like having a boolean type in other languages, I am not convinced
that it would be a worthwhile addition to LPC.


Par Winzell <zell at ncal.verio.com> wrote:

>[...]
> Previously, 0 was clearly not only false, but -the- false. Everything that
> now results in nil resulted in zero. Yearning for true booleans meant
> discarding a consistent (if slightly ugly) system for the promise of
> something better.
>
> Now, things are different. There is a new false in town, 'nil', and it is
> clearly the superior one. Numbers 0 and 0.0 are reduced to convenient
> aliases for nil in comparisons, really, just as non-nil, non-zero values
> are aliases for truth. With a new value introduced whose only purpose in
> life is to be false, half of a real boolean system is suddenly in place,
> making it all the more attractive to take the last step.

I think that considering `nil' the only genuine false is a lisp-ism
that is inappropriate for LPC.  As it stands, there simply is no
boolean type.  A case can be made for an implied boolean type in
if/while/for statements and expressions containing the !, && and ||
operators, but neither the arguments nor the results are booleans.


>[...]
> The only alternative I can think of is this: introduce a boolean type and
> a truth value, letting nil be false. Let ! always map into this type, and
> make 0 and 0.0 aliases for nil in comparisons the same way all non-nil
> strings, arrays, objects and mappings are aliases for true. This allows
> e.g.
>
>         if (!some_number == !this_object()) { ... }
>
> for all those of you who don't want to have to compare integers explicitly
> with zero. :-)
>
> Is this consistent?

Again, I disagree.  It would be rather pointless to add a boolean
type to LPC if doing so did not result in significantly stronger
typechecking.  Otherwise, the benefits of booleans would be barely
above what could be accomplished with a few #defines.

Regards,
Dworkin

List config page:  http://list.imaginary.com/mailman/listinfo/dgd