Re: Overloaded logic operators

Torben Fgidius Mogensen wrote:
> Strictly speaking, this is a question of language design and not
> compilers, except where the design influences ease of compilation.


This is true, and I do participate in language design groups also. Please
forgive me if this is not on topic.


> Basically, there are two ways I have seen of extending logical operators:
>
> 1. Let the default boolean type be a type with more than two values,
> such as integers, extend operators to all values and define which
> subset corresponds to True and which to False.
>
> 2. Include a null value that is present in all types and let logical
> operators treat the null value a False and all other values as
> True.
  >
> Option 1 is chosen by, e.g., C and many versions of BASIC, and logical
> operators are typically extended to bitwise operations (though C also
> includes sequential logical operators that are not bitwise).
> Typically, 0 is treated ad False and all nonzero values as True. This
> has the odd implication that AND'ing two True values may give False
> and that two True values do not compare as equal. In C, comparison
> operators return 1 as True, while in most BASIC variants, -1 is
> returned. The latter has the advantage of being the bitwise negation
> of 0 (if you use two's complement numbers, which is nearly universal
> now). C's sequential operators && and || are more like if-then-else,
> with p && q being equivalent to (p ? q : p) and p || q being
> equivalent to (p ? p : q).
>


The short-circuit semantics of "and" and "or" of most languages feel
un-orthogonal, like they are treated special compared to other operators. I
love the way Smalltalk handles this with block closures:


(a > b) ifTrue: [] ifFalse: []


While I like the semantics, I'm not the biggest fan of the syntax - it can be
confusing for beginners to know when to use ()s and []s.


> Option 2 is chosen by some scripting languages and "p and q" is
> typically equivalent to "if p == null then p else q" and "p or q"
> equivalent to "if p == null then q else p", so very similar to C's
> sequential operators. There is, however, no obvious implementation of
> logical negation. If the argument is non-null, the result is
> obviously null, but if the argument is null, there is no obvious
> value. If the language is dynamically typed, you don't even know
> which type the result should have. Similarly, comparison operators
> should return a non-null value when the comparison yields True. If
> you have a boolean type that has exactly one non-null values, you can
> use this value in both cases. If you have an Object class (top of the
> inheritance hierarchy), this might be used.


I like this idea of nil and Object. true needs false... now you've got two
falsey values - and it's all downhill from there :) Do you know of languages
which use this technique?


> Generally, I don't like including null-values in all types, as this
> require functions to test for null-values all the time.


Although I've looked into languages such as Haskell, SML and Dylan, I haven't
had enough experience with non-null valued languages. Actually, C++
references, in a way are non-null pointers are they not?


>> x = x > 0 # if x is > 0, x, else false
>
> This makes > and < assymetrical: x > 0 is not the same as 0 < x, and
> they might not even have the same type (unless null/false is included
> in all types). It could lead to subtle bugs which get even worse if x
> itself might be a null value (what is the value of false==y?).


Yeah, this is looking more and more like a bad idea. :)


> In any case, I don't see the above as ad-hoc overloading of logical
> operators, more like defining them on the Object type and by
> inheritance on all other types, which is a kind of overloading, but
> not in an ad-hoc fashion.


Thanks for your input!

Return to the comp.compilers page.
Search the comp.compilers archives again.