Re: Overloaded logic operators

Bartc wrote:
> "Mike Austin" <mike@mike-austin.com> wrote in message
>> In many languages, logic operators "and" and "or" have been overloaded to
>> handle more than booleans. For example:
>>
>> x = x or 0 # if x is nil, 0
>
> You mean that in (x or y), it will return the first of x or y that is
> not false? Or can you only compare against False?
>
> In that case, the above is a no-op: it will set x to x when x is True, and
> to False when x is False.


Yes, a no-op for a language which treats non-null as true, or an error which
treats "and" and "or" as boolean operators only.


>> x and x.foo() # if x is not nil, call foo
>
> Not so interesting, you can just do: if x then x.foo()


Or if x != nil then x.foo()


for boolean-only comparisons, which is a little long winded.


>> x = x > 0 # if x is > 0, x, else false
>>
>> I'm torn between this being easier for the programmer, or just bad
>> practice in general.
>>
>> It enables you do to tricks like this:
>>
>> x = -1 < x < 1 or 0
>
> What you're saying is that the relational operators return the actual value
> that caused the True result, rather than just True?


Yes. This was how the language Io originally worked, for example. It's
interesting, but I think it was changed because of confusion and the
asymmetrical nature of it.


> This example is confusing anyway as to what you're setting x to. Or as to
> what is the result of (-1<x<1); if (-1<x) returns x, then x<1 should return
> 1? Then the 'or 0' is not needed.
>
> (Being able to write if a<b<c is neat though and I've just added that
> to my language, with about 5 lines of code; it just converts to if
> (a<b) and (b<c).)


So you chose syntactic sugar over consistency? I'm not saying that's
bad, just that you can't write (a<b)<c, correct?


>> but it also means your booleans are values, and you can't test "if x ==
>> true",
>> but only "if x != nil"
>
> No, but you'd normally write if x, not if x=true
>
>> In languages such as Ruby, Lua, Io, Python and JavaScript, does the
>> benefit outweigh the effect of overloaded logic?
>
> I think and/or are not overloaded for good reasons, because you need extra
> effort to get your mind around them. Although the behaviour you're
> describing (using zero/not zero instead of False/True) is fairly typical and
> wouldn't be considered overloading.


I guess it comes down to the question, does "1 or 2" make sense - does
it match the semantics of the rest of the language. "non-false" or
"non-nonfase".


Thanks for the input!
Mike

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