Tue, 25 Nov 2008 01:10:53 -0800

Related articles |
---|

Overloaded logic operators mike@mike-austin.com (Mike Austin) (2008-11-23) |

Re: Overloaded logic operators mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2008-11-24) |

Re: Overloaded logic operators torbenm@pc-003.diku.dk (2008-11-24) |

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

[5 later articles] |

From: | Mike Austin <mike@mike-austin.com> |

Newsgroups: | comp.compilers |

Date: | Tue, 25 Nov 2008 01:10:53 -0800 |

Organization: | at&t http://my.att.net/ |

References: | 08-11-110 08-11-115 |

Keywords: | design |

Posted-Date: | 25 Nov 2008 07:06:36 EST |

Torben Fgidius Mogensen wrote:

*> Strictly speaking, this is a question of language design and not*

*> compilers, except where the design influences ease of compilation.*

This is true, and I do participate in language design groups also. Please

forgive me if this is not on topic.

*> Basically, there are two ways I have seen of extending logical operators:*

*>*

*> 1. Let the default boolean type be a type with more than two values,*

*> such as integers, extend operators to all values and define which*

*> subset corresponds to True and which to False.*

*>*

*> 2. Include a null value that is present in all types and let logical*

*> operators treat the null value a False and all other values as*

*> True.*

>

*> Option 1 is chosen by, e.g., C and many versions of BASIC, and logical*

*> operators are typically extended to bitwise operations (though C also*

*> includes sequential logical operators that are not bitwise).*

*> Typically, 0 is treated ad False and all nonzero values as True. This*

*> has the odd implication that AND'ing two True values may give False*

*> and that two True values do not compare as equal. In C, comparison*

*> operators return 1 as True, while in most BASIC variants, -1 is*

*> returned. The latter has the advantage of being the bitwise negation*

*> of 0 (if you use two's complement numbers, which is nearly universal*

*> now). C's sequential operators && and || are more like if-then-else,*

*> with p && q being equivalent to (p ? q : p) and p || q being*

*> equivalent to (p ? p : q).*

*>*

The short-circuit semantics of "and" and "or" of most languages feel

un-orthogonal, like they are treated special compared to other operators. I

love the way Smalltalk handles this with block closures:

(a > b) ifTrue: [] ifFalse: []

While I like the semantics, I'm not the biggest fan of the syntax - it can be

confusing for beginners to know when to use ()s and []s.

*> Option 2 is chosen by some scripting languages and "p and q" is*

*> typically equivalent to "if p == null then p else q" and "p or q"*

*> equivalent to "if p == null then q else p", so very similar to C's*

*> sequential operators. There is, however, no obvious implementation of*

*> logical negation. If the argument is non-null, the result is*

*> obviously null, but if the argument is null, there is no obvious*

*> value. If the language is dynamically typed, you don't even know*

*> which type the result should have. Similarly, comparison operators*

*> should return a non-null value when the comparison yields True. If*

*> you have a boolean type that has exactly one non-null values, you can*

*> use this value in both cases. If you have an Object class (top of the*

*> inheritance hierarchy), this might be used.*

I like this idea of nil and Object. true needs false... now you've got two

falsey values - and it's all downhill from there :) Do you know of languages

which use this technique?

*> Generally, I don't like including null-values in all types, as this*

*> require functions to test for null-values all the time.*

Although I've looked into languages such as Haskell, SML and Dylan, I haven't

had enough experience with non-null valued languages. Actually, C++

references, in a way are non-null pointers are they not?

*>> x = x > 0 # if x is > 0, x, else false*

*>*

*> This makes > and < assymetrical: x > 0 is not the same as 0 < x, and*

*> they might not even have the same type (unless null/false is included*

*> in all types). It could lead to subtle bugs which get even worse if x*

*> itself might be a null value (what is the value of false==y?).*

Yeah, this is looking more and more like a bad idea. :)

*> In any case, I don't see the above as ad-hoc overloading of logical*

*> operators, more like defining them on the Object type and by*

*> inheritance on all other types, which is a kind of overloading, but*

*> not in an ad-hoc fashion.*

Thanks for your input!

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.