Charles, Are you saying that your patches are still not applied in the SVN distribution, or that there are remaining bugfixes needed, or that OVLD is presently usable thanks to your work on them? I know we iterated, and you have committed some needed fixes, but this message makes it sound kind of like your patches still have not been addressed. I did some and then made you a committer so that you could maintain it, is that right? By the way, thank you for working on overloading, since Sudarshan has not remained active here.
My general recollection is that before the recent patches needed due to the addition of some new thread communication operators, the last time or two that I used OVLD it felt like the feature needed more testing before I would recommend that folks trust it. ovld.icn is a good step towards having some test coverage for it, it should probably have an &feature check added to the top, and then it should be added to tests/unicon Cheers, Clint ________________________________________ From: Charles Evans <cvev...@users.sourceforge.net> Sent: Tuesday, January 28, 2014 2:26 PM To: unicon-group@lists.sourceforge.net Subject: Re: [Unicon-group] [Unicon-ldif] Overloaded operators? 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 ------------------------------------------------------------------------------ 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
