[890] in Coldmud discussion meeting

[COLD] Re: a thought about the new, improved + operator...

daemon@ATHENA.MIT.EDU (Tue Jan 9 21:45:28 1996 )

Date: Tue, 9 Jan 1996 19:27:07 +0000 ()
From: Brandon Gillespie <brandon@tombstone.sunrem.com>
To: coldstuff@tombstone.sunrem.com
In-Reply-To: <Pine.BSD/.3.91.960109173026.563I-100000@pentagon.io.com>
Reply-To: coldstuff@tombstone.sunrem.com

On Tue, 9 Jan 1996, Kor wrote:
> Robert Lumley and I were talking, recently, about the snifty new addition
> of automatic conversion to string via the '+' operator.  we were thinking
> that there is a potential danger in hiding the means of conversion from the
> programmer, so we were wondering about the possibility of operator
> overloading...  the same task could be accomplished without hiding the
> means of operation, and it could also be broadly applied other ways.  I'd
> also rather like it if new operators could be defined.  it could make for
> some very nice looking, clean code.
>
> one problem I see is that this could make for some really strange oddments
> that would be made up to look like something else, even though they parsed
> out in coldc via overloaded operators.
>
> anyhow, comments?

I have oft considered having operator overloading, and unfortunately 
cannot come up with a simple solution (simple being short of rewriting 
how the current interpreter and parser works).

The problem comes in with how operators are 'looked up'.  There are many 
ways this could be changed to handle overloading, but no matter which way 
it is, it is not very efficient.  What it boils down to is that in our 
current run-time environment operator overloading is not a very good option
because the interpreter makes several assumptions for speed, which would 
have to go away.

The other solution would be to rewrite the interpreter.  Frankly I'm not 
too enthusiastic about that at this moment; I have too many other 
projects :b

-Brandon