Re: Overloaded logic operators

"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.


> x and x.foo() # if x is not nil, call foo


Not so interesting, you can just do: if x then x.foo()


> 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?


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).)


> 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.


--
Bartc

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