Re: CLOS usage
Posted: Thu Jul 10, 2008 12:13 am
Yes, I thought so, but wasn't sure
Discuss and learn Lisp programming of all dialects. NOTICE: Site locked. No new users or posts.
http://www.lispforum.com/
Well, I was really excited about (pure) functional stuff when I first got interested in Haskell, after coming from the pain of C++ and the verbose boulder-dragging of Java. Then I saw some stack traces which kind of stopped me in my tracks.pTymN wrote:Seriously, a stack trace that is 100% meaningful, where I don't have to play detective to figure out why the values I am looking at are what they are... that would be nice to have all the time.
In CLOS, you are still using functions. The best way to think about CLOS is that what you're writing is generic functions. (This is clearer if you always write explicit defgenerics, rather than letting CLOS put them in automatically.) From the caller's point of view, it's just a function! The defmethod's are part of the internal implementation of the function. When is it good to implement a function using this (defmethod) mechanism. Well, if you're going to do different implementations of the same concept based on the type (subclass, in practice) of one (or more!) of your arguments, then it's perfect.Alexander Lehmann wrote:Hm, I like CLOS and fairly often use objects. However, I prefer using "regular" functions instead of methods wherever methods aren't explicitly neccessary.
The quality of the error messages depends primarily on which implementation of Common Lisp you're using. There are eleven of them out there still being maintained actively (see http://common-lisp.net/~dlw/LispSurvey.html). I've been happy with the error messages in SBCL and CCL (OpenMCL), and the stack traces.Exolon wrote:pTymN wrote:That's also something that I find a little painful with Lisp; especially the lack of line numbers in the uncaught/REPL error handler stack traces, but the generally mystifying nature of error messages I've been getting as a newbie to the language. There's a lot to be said for messages like "Array index out of bounds (CarThingy.java, line 85)" and a backtrace which lists the classes (usually = files) and line numbers of the higher stack frames.
Sorry, I'm having a lot of trouble understanding what you mean by things like "(X A X')" and "obj.A".pTymN wrote:It has always seemed to me that CLOS is a product of that age when it was in vogue to make everything object oriented. Now, it was written in Lisp, so I know that CLOS and Smalltalk are probably the highlights of OO and the C++ that I use in my day job has prematurely turned me off from OO, but I don't think that is the whole story. In Lisp, it has been so trivial to build up a data structure, store it, retreive it and destroy it just a few methods later, that I feel no need to ever make a heavyweight solid data structure of the type that OO champions. Another problem with OO is that it tends to limit exactly how code can get reused. The structureless nature of Lisp allows me to take any meaningful chunk of code and not just put code before or after it, but to take callbacks (which are so awkward in C++ that for the first ten years, I had to look up the syntax), and make them trivial, so that I can make a piece of code that is designed to be (X A X') with your custom chunk A in the middle. In an OO paradigm, the callback would be to call out to obj.A and to overload A. At least java made everything virtual. I cannot tell you how much pain that causes me, when the child class doesn't even get the final say over which versions of methods will be used 100% of the time. Sorry for the rant, I just hope that OO has the mark of shame all over it when stateless functional programming takes over. Seriously, a stack trace that is 100% meaningful, where I don't have to play detective to figure out why the values I am looking at are what they are... that would be nice to have all the time.
Please correct me if I'm wrong, but I thought that the major difference between "functions" and "methods" -- with respect to Lisp and/or CLOS -- was that for methods, CLOS first looks up the most suitable (specialized) version of a method in regard to the given parameters, whereas this need not be done for plain "functions"?dlweinreb wrote:In CLOS, you are still using functions. The best way to think about CLOS is that what you're writing is generic functions. (This is clearer if you always write explicit defgenerics, rather than letting CLOS put them in automatically.) From the caller's point of view, it's just a function! The defmethod's are part of the internal implementation of the function. When is it good to implement a function using this (defmethod) mechanism. Well, if you're going to do different implementations of the same concept based on the type (subclass, in practice) of one (or more!) of your arguments, then it's perfect.Alexander Lehmann wrote:Hm, I like CLOS and fairly often use objects. However, I prefer using "regular" functions instead of methods wherever methods aren't explicitly neccessary.
What you are calling methods are actually generic functions. Methods are simply function-like elements associated with generic functions. dlweinreb's point was that plain functions and generic functions can be used in the same manner, although the internals are quite different.Alexander Lehmann wrote:Please correct me if I'm wrong, but I thought that the major difference between "functions" and "methods" -- with respect to Lisp and/or CLOS -- was that for methods, CLOS first looks up the most suitable (specialized) version of a method in regard to the given parameters, whereas this need not be done for plain "functions"?