Tue, 25 Nov 2008 14:57:35 +0100

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

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.