Re: Overloaded logic operators

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Tue, 25 Nov 2008 14:57:35 +0100

          From comp.compilers

Related articles
[3 earlier articles]
Re: Overloaded logic operators bc@freeuk.com (Bartc) (2008-11-24)
Re: Overloaded logic operators arnold@skeeve.com (2008-11-25)
Re: Overloaded logic operators mike@mike-austin.com (Mike Austin) (2008-11-25)
Re: Overloaded logic operators mike@mike-austin.com (Mike Austin) (2008-11-25)
Re: Overloaded logic operators mike@mike-austin.com (Mike Austin) (2008-11-25)
Re: Overloaded logic operators lkrupp@pssw.com (Louis Krupp) (2008-11-25)
Re: Overloaded logic operators mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2008-11-25)
Re: Overloaded logic operators m.helvensteijn@gmail.com (2008-11-25)
Re: Overloaded logic operators bc@freeuk.com (Bartc) (2008-11-25)
Re: Overloaded logic operators cdodd@acm.org (Chris Dodd) (2008-11-25)
Re: Overloaded logic operators torbenm@pc-003.diku.dk (2008-11-26)
Re: Overloaded logic operators fswarbrick@gmail.com (Frank Swarbrick) (2008-11-27)
Re: Overloaded logic operators dot@dotat.at (Tony Finch) (2008-12-01)
[2 later articles]
| List of all articles for this month |

From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.compilers
Date: Tue, 25 Nov 2008 14:57:35 +0100
Organization: cbb software GmbH
References: 08-11-110 08-11-114 08-11-120
Keywords: design
Posted-Date: 25 Nov 2008 14:50:09 EST

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


Post a followup to this message

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