Re: Overloaded logic operators

On Tue, 25 Nov 2008 00:39:31 -0800, Mike Austin wrote:


>>> x = x or 0 # if x is nil, 0
>>> x and x.foo() # if x is not nil, call foo
>>> x = x > 0 # if x is > 0, x, else false
>>
>> Is "=" an assignment or equality here? What are the association priorities
>> of the operations "=", ">" and "or"? What are the types involved? Do you
>> mean short circuit operations, which do not evaluate their arguments
>> eagerly?
>
> = as assignment, and I'm specifically interested in null/non-null values for x.


OK, I see what you meant under overloading. In general, I have no problem
with that. But it must be typed. So if x is a pointer-to-number then


      x = x or 0


is meaningless, because the result is either a pointer or else 0.


> I should rephrase my first line as "return values based on the
> operators, rather than returning true or false". Yes, I do mean
> short circuit operations.
n
There is a simpler (and also consistent) approach to this. Take IEEE
numbers as an example. They just added some ideals to the set of numeric
values in order to do the thing you want.


Make nil a "value" of the type of x, like NaN is of an IEEE number. Then
define extended operations with nil, provided "or" was already defined on
x. For example, it can consume nil:


      forall x, (x or nil) = x (= is equivalence here)


When you extend operations like "and", "or" etc you should preserve they
"intuitive" properties (of being a lattice, e.g. de Morgan rules etc).
Similar should be done with ">" (transitivity of, etc). I think you will
have problems with ">": x > 0 should be equivalent to both


      0 < x (0 if 0<x ?)


and


      not (x <= 0)


>> As for macro expressions -1 < x < 1 or 0, which I suppose should read:
>>
>> (-1 < x) and (idem < 1) or (idem < 0)
>
> If a comparison operator returned (this makes them asymmetrical, as Torben has
> pointed out). It could return the higher number, or the non-literal, or ...:
>
> ((-1 < x) and (x < 1)) or 0
>
> or put another way:
>
> (-1 < x && x < 1) ? x : 0


That is ill-defined. Consider:


      x < y or 0


it is unclear what to take as the result, x or y? The expression must be a
function of its arguments. It would be very confusing when literals like 1
in your formula had a different treatment than variables like x.


--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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