On Tue, 21 Jan 2014 20:21:44 +0000 "Jeffery, Clint (jeffe...@uidaho.edu)" <jeffe...@uidaho.edu> wrote:
> There is an implementation of operator overloading that was done by > Sudarshan Gaikaiwari I think, under the #ifdef symbol OVLD. It is not > enabled by default. It looks a little different than you propose here. It > likely would require some updates to account for changes made since it was > implemented. At the time it was considered a complete implementation, but > was not heavily tested nor considered rock-solid stable yet. It has not > been adopted in the language thusfar, partly for philosophical reasons. > > Ralph Griswold would say that referential transparency is important, and > that not knowing whether the expression x+y has anything to do with > addition would make code less readable and maintainable. The Java language > designers apparently agreed, eschewing the overloading that C++ took on in > order to try and kill Ada. > > Personally, I am ambivalent, wanting classes to be able to define new types > that feel just as native as built-in types, but somewhat sympathetic to > Griswold's point of view. > > Clint > ________________________________________ > From: Steve Wampler <swamp...@noao.edu> > Sent: Tuesday, January 21, 2014 12:03 PM > To: Unicon-features > Subject: [Unicon-ldif] Overloaded operators? > > Is anyone still working on adding operator overloading to Unicon? I sent in patches to fix the overloading a year or 2 ago at http://sourceforge.net/p/unicon/bugs/122/ and a preliminary test prog ovld.icn: http://sourceforge.net/p/unicon/bugs/122/#4739 ^ usage: http://sourceforge.net/p/unicon/bugs/122/?limit=10&page=1#2e4f If it needs an update, please add your info to the bug. I would also welcome more tests. If you have any questions, I am more than glad to help. If you are new to OVLD, please remember: If doing a math library for others, your __*__ methods must NOT modify themselves in any way that matters outside unless the corresponding op modifies its args. There are a few things you should know about the current state of the runtime: I only tested the binary ops with l.h.s. classes, e.g. Complex(5,8) - 5 IIRC 5 - Complex(5,8) will require an improvement in the runtime: It requires a method __rminus__() to be called automatically [to-do] (or else we must find a way for the runtime to tell method __minus__() that this time self is the r.h.s. -- and then it must check this in its icon code, after the checking in the C code. I favor adding the rminus). __rplus__() would just call __plus__() in this case. The library classes will be large either way, with or without OVLD. Until then, any possibly non-complex, non-polymorphic l.h.s. var x needs for example Complex(x) before use with a possibly complex r.h.s, and any constant l.h.s. that may ever face a complex r.h.s. y needs Complex(5)+ y; This is of course slower and uses more memory. In my limited (past) experience, even a small OO math program will be more readable with sane overloaded operators (much more readable once you have __r*__). If Lisp is your primary language, YMMV. Sane usually includes (for me) that no method __*__() exists unless not calling it would produce a runtime error or a silly result. It should not cause any side effects unless the corresponding operator does. One of the few exceptions would be for example x:=Complex(3); !x If a call should produce a runtime error, remember to runerr(). With the exceptions well documented as such, I find my programs very readable and maintainable. (OTOH if you define __plus__ to do **, or do write:=proc("+",1) you lose, overloads or no. I see no difference.) If you will have to maintain much of your own OO math code, I expect you will find it well worth the drudgery of writing the __*__ methods. If Lisp is your primary language, YMMV. Once you look at writing libraries to do for example array ops on complex, I think you will find operator overloading almost a necessity. Theoretically, with rminus, etc, an array op class should handle complex class number math transparently, BUT: Methods using or providing functions do not benefit as much from OVLD as it is now: they still need to test all incoming data for class types -- a generic-array method write() must be check each element, to do x[n].write() as needed -- unless we decide to accept overloaded functions. If we do, we may want the runtime to limit all but a few specific functions to only activate any overloading when they would otherwise throw a runtime error or produce a useless result such as "record(3)". This keeps the runtime cost to a minimum; I think it will also limit surprises. I have found overloaded functions very useful: Once you have the appropriate libraries, they often make OO math programs almost as easy to read and write as programs that use only much simpler data types. They also greatly simplify writing polymorphic functions, allowing re-use of libraries that you can still read, even if you did not write them. With them, an OO math library can provide higher math functions that are just as user-friendly as the basic operations. If you need good speed or efficiency, your OO math library classes will usually need to be much larger still, with or without OVLD. If you also want to write easy-to-read application code, we can discuss the next level of operator overloading, augmented assignment. I hope to hear your thoughts on OVLD here or on [reply-to] unicon-l...@lists.sourceforge.net Charles ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
