Related articles |
---|
[11 earlier articles] |
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) |
Re: Overloaded logic operators alexc@TheWorld.com (Alex Colvin) (2008-12-03) |
Re: Overloaded logic operators haberg_20080406@math.su.se (Hans Aberg) (2008-12-04) |
From: | Hans Aberg <haberg_20080406@math.su.se> |
Newsgroups: | comp.compilers |
Date: | Thu, 04 Dec 2008 20:44:52 +0100 |
Organization: | Aioe.org NNTP Server |
References: | 08-11-110 |
Keywords: | syntax, design |
Posted-Date: | 04 Dec 2008 15:07:11 EST |
Mike Austin wrote:
> In many languages, logic operators "and" and "or" have been overloaded to
> handle more than booleans.
...
> I'm torn between this being easier for the programmer, or just bad
> practice in general.
It is not the operator overloading that is causing problems, but
implicit type conversions, especially in the case where it loses some
information. The problem is that the effects of such syntax is hard to
detect when debugging.
So, for example, converting (multiprecision) integers to rational
numbers is safe, but converting rational numbers to floats might cause
some unexpected things: unequal numbers may be treated as equal, for
example. Converting floating point numbers implicitly to integers is
bad, because such conversions may need some guards against round-off
errors.
> In languages such as Ruby, Lua, Io, Python and JavaScript, does the
> benefit outweigh the effect of overloaded logic?
One such example is C, where it was problematic in C++, wanting to keep
the C syntax.
Hans
Return to the
comp.compilers page.
Search the
comp.compilers archives again.