Would someone be kind enough to explain the following...
a) (set-background IMAGE) ; works
b) (set-background 100 100 100 255) ; works
c) (set-background 100 100 100) ; fails - "Wrong number of arguments"
My code is below:
(defclass color ()
(
(r :accessor r :initarg :r)
(g :accessor g :initarg :g)
(b :accessor b :initarg :b)
(a :accessor a :initarg :a)))
(let ((bground nil))
(defmethod set-background ((background image))
(setf bground background))
(defmethod set-background ((r integer) (g integer) (b integer) (a
integer))
(if (typep bground 'color)
(progn
(setf (r bground) r)
(setf (g bground) g)
(setf (b bground) b)
(setf (a bground) a))
(setf bground (make-instance 'color :r r :g g :b b :a a)))
bground)
(defmethod set-background ((r integer) (g integer) (b integer))
(set-background r g b 255))
(defmethod background ()
bground))
set-background should be defined only once, with 4 parameters, and with
the last parameter being optional. Search for &optional on this page:
http://www.gigamonkeys.com/book/functions.html
I don't know CLOS yet, but I assume the syntax for methods is similar
to the syntax for functions. You are allowed to make several versions
of a method which take different types of parameters, but they all need
to take the same number of parameters.
Here is the simple test program I wrote to check whether it was okay
for two methods with the same name to have different number of
arguments:
(defmethod combine ((x integer) (y integer) (z integer))
(list x y z))
(defmethod combine ((x integer) (y integer))
(list x y))
LispWorks liked the first method. But it complained about the second:
Error: Lambda list (X Y) is not congruent with the lambda list (X Y Z)
of the generic function #<STANDARD-GENERIC-FUNCTION COMBINE
I made a mistake in my first post. I didn't notice that your call to
(set-background IMAGE)
worked correctly. Anyway, I think creating an optional argument will
still solve your problem. Something like this:
(defmethod combine (x y &optional (z 255))
(list x y z))
(combine 1 2 3) --> (1 2 3)
(combine 1 2) --> (1 2 255)
I don't know how to specify both a default value and a type
specification, though. Another possibility is to use (z integer),
accept the default value of z=nil, and add (if (null z) (setf z 255))
to the beginning of the method.
Good luck.
No, that dooes not give me the result I want.
I want my code to look something like this:
(set-background AN-IMAGE) ; Set background to a static image
(set-background AN-ANIM) ; Set background to display a video
(set-background 255 255 255) ; Set background to a single color of the
format r g b
(set-background 255 255 255 100) ; Set background to a single color
with a transparency
(set-background 100) ; Convert the specified 8-bit color to r g b with
default 255 level transparenct
Doing all of this with keywords defeats the point of having CLOS. And
not being able to specify a parameter type means that all the code for
determing the type needs to be in the method body.
-Luke
Luke Crook wrote:
> No, that dooes not give me the result I want.
>
> I want...
"your wants and your desires are the source of all your unhappiness."
-- Buddha
... my code to look something like this:
>
> (set-background AN-IMAGE) ; Set background to a static image
> (set-background AN-ANIM) ; Set background to display a video
> (set-background 255 255 255) ; Set background to a single color of the
> format r g b
> (set-background 255 255 255 100) ; Set background to a single color
> with a transparency
> (set-background 100) ; Convert the specified 8-bit color to r g b with
> default 255 level transparenct
I see. So you do not want to use Lisp. Full stop. (Hint: if you want to
use language X, find out how it works before you write the code for the
language you have fantasized and compile it as X.)
>
> Doing all of this with keywords defeats the point of having CLOS.
I see. You know not even the most primitive fact about how CLOS works
(witness the code you offered), but you are prepared to sermonize on the
point of having it. Go directly to cll jail, do not collect $100.
> And
> not being able to specify a parameter type means that all the code for
> determing the type needs to be in the method body.
<sob> Oh the humanity! <\sob>
This is easy. You have made one great honking error: GFs are not C++
overloading. They went in a different direction. I will not even bother
with which is better. Pick Lisp or pick C++ and get on with your life
(you really do need to use the language you have chosen to use, not some
other language).
Or (untested):
(defun set-background (r &optional g b a)
(setf bground
(cond
((null g) r)
((null b) (break "dream on"))
(t (make-color :r r :g g :b b (or a 255)))))
Yes, lose that optimization (not!) where you set the slots of a color
instance rather than make a new color (and relatively slow GFs now sleep
with the fish).
hth, kt
--
Cells? Cello?: http://www.common-lisp.net/project/cells/
Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> Luke Crook wrote:
> > (set-background 100) ; Convert the specified 8-bit color to r g b
with
> > default 255 level transparenct
>
> I see. So you do not want to use Lisp. Full stop. (Hint: if you want
to
> use language X, find out how it works before you write the code for
the
> language you have fantasized and compile it as X.)
>
> I see. You know not even the most primitive fact about how CLOS works
> (witness the code you offered), but you are prepared to sermonize on
the
> point of having it. Go directly to cll jail, do not collect $100.
I don't think I was preaching, expounding perhaps. And now I'm thrown
in jail to boot?
Background: I'm trying to make my CCL code look almost exactly unlike
that of the java-based processing.org. Here is a sample:
....
void setup()
{
size(200, 200);
noStroke();
colorMode(RGB, 255, 255, 255, 100);
rectMode(CENTER);
}
void draw()
{
background(51);
fill(255, 80);
rect(mouseX, height/2, mouseY/2+10, mouseY/2+10);
fill(255, 80);
rect(width-mouseX, height/2, ((height-mouseY)/2)+10,
((height-mouseY)/2)+10);
}
....
Clean, straight forward. Easy to read and understand. Here is my
current CLL code:
....
(let ((width 640) (height 480) (mousex 0) (mousey 0))
(sdl:init ()
(sdl:window width height)
(set-background 255 255 255 255)
(sdl:handle-events
(:quit t)
(:mousemotion (state x y xrel yrel)
(setf mousex x
mousey y))
(:idle
(draw (set-background 255 255 255 255))
(sdl:box mousex (/ height 2) (+ (/ mousey 2) 10)
(+ (/ mousey 2) 10) 0 0 255 :alpha 100 :rectmode
'center)
(sdl:box (- width mousex) (/ height 2)
(+ (/ (- height mousey) 2) 10) (+ (/ (- height
mousey) 2) 10) 0 255 0 :alpha 100 :rectmode 'center)
(sdl:Flip)))))
....
My code is not quite there yet. I'll probably roll SDL:INIT into
SDL:WINDOW, but SDL:INIT also shuts down libsdl upon exit which is
nice. SDL:FLIP can be rolled into the SDL:HANDLE-EVENTS macro. I can
get rid of the WIDTH & HEIGHT variables by having SDL:WINDOW assign
these to local variables that may be retrieved using the functions
(WIDTH) & (HEIGHT). Something similar can be done with mouseX and
mouseY, having SDL:HANDLE-EVENTS set these, retrieving the values with
the functions (mouseX) and (mouseY).
This leaves SET-BACKGROUND. It would be great if (BACKGROUND) returns
the background, and (BACKGROUND image/r g b/r g b a) sets the
background. As you pointed out this is not possible in Lisp - which is
kind of weird, Lisp being the Borg of languages and all. So I will
either have to compromise, or go down a different path. Perhaps your
defun suggestion, or perhaps a (set-background (color 255 255 255))
would not be too bad.
> Pick Lisp or pick C++ and get on with your life
> (you really do need to use the language you have chosen to use, not
some
> other language).
I picked Lisp. Now I want to make Lisp look like 'processing'. That
Sir, is no crime.
-Luke
Luke Crook wrote:
> Kenny Tilton wrote:
>
>>Luke Crook wrote:
>>
>>>(set-background 100) ; Convert the specified 8-bit color to r g b
>
> with
>
>>>default 255 level transparenct
>>
>>I see. So you do not want to use Lisp. Full stop. (Hint: if you want
>
> to
>
>>use language X, find out how it works before you write the code for
>
> the
>
>>language you have fantasized and compile it as X.)
>>
>>I see. You know not even the most primitive fact about how CLOS works
>
>
>>(witness the code you offered), but you are prepared to sermonize on
>
> the
>
>>point of having it. Go directly to cll jail, do not collect $100.
>
>
> I don't think I was preaching, expounding perhaps. And now I'm thrown
> in jail to boot?
>
> Background: I'm trying to make my CCL code look almost exactly unlike
> that of the java-based processing.org. Here is a sample:
>
> ....
> void setup()
> {
> size(200, 200);
> noStroke();
> colorMode(RGB, 255, 255, 255, 100);
> rectMode(CENTER);
> }
>
> void draw()
> {
> background(51);
> fill(255, 80);
> rect(mouseX, height/2, mouseY/2+10, mouseY/2+10);
> fill(255, 80);
> rect(width-mouseX, height/2, ((height-mouseY)/2)+10,
> ((height-mouseY)/2)+10);
> }
> ....
>
> Clean, straight forward. Easy to read and understand.
Yes. But since this is Java you have to tell us what these methods are
from.
I really really like the title of the Chapter on CLOS in PCL: "Object
Re-orientation". You need to go with the flow. You are rowing against
it instead. Relax. The flow is very nice.
Cheers
--
Marco
Marco Antoniotti wrote:
> Yes. But since this is Java you have to tell us what these methods
are
> from.
The above 'processing' code is the whole program, start to finish.
There are no other classes or objects defined.
I'm not sure how much actual Java (the language) is used. 'Processing'
utilizes the JVM so that applications can run as applets in a browser.
-Luke
Luke Crook wrote:
> Marco Antoniotti wrote:
>
>>Yes. But since this is Java you have to tell us what these methods
>
> are
>
>>from.
>
>
> The above 'processing' code is the whole program, start to finish.
> There are no other classes or objects defined.
>
> I'm not sure how much actual Java (the language) is used. 'Processing'
> utilizes the JVM so that applications can run as applets in a browser.
>
Ok. My bad. However, this "processing" little language is sweeping a
lot under the cover. In any case, using an explicit "color" instance is
better.
Cheers
--
Marco
Woa, Kenny, I thought you were against barbecuing the newbies.
--
Fred Gilham ······@csl.sri.com
The PTPL (People's Trotskyist Programming League) believes that
hackers are elitist and that all software should be created by the
masses flailing away at millions of keyboards. I didn't have the
heart to tell them that this has already been tried and the result is
called Linux.
Fred Gilham wrote:
> Woa, Kenny, I thought you were against barbecuing the newbies.
>
>
(a) jeez, I fixed his code for him.
(b) You are showing our age, Fred. Google reports that Luke dropped Lisp
Newbie Question #1 into c.l.l. on Jan 17, 2002. Only a dinosaur like us
would consider 3+ years a newbie.
(c) Let the roast resume!
Luke J Crook wrote (from now on):
> It would be great if (BACKGROUND) returns
> the background, and (BACKGROUND image/r g b/r g b a) sets the
> background. As you pointed out this is not possible in Lisp - which is
> kind of weird, Lisp being the Borg of languages and all.
You are looking for Borg in the syntax.
Restarts:
(1) Resume execution under GCC
(2) Enter some Lisp syntax to use instead
(3) Abort and go look for Borg somewhere else
(4) Retry after insulting Lisp for dispatching on something more
sensible than function signature. Look forward to seeing this backtrace
shortly.
> So I will
> either have to compromise, or go down a different path. Perhaps your
> defun suggestion, or perhaps a (set-background (color 255 255 255))
> would not be too bad.
Oh, gosh, I /did/ help him! A fine barbecue chef I would make, serving
live chickens.
> Background: I'm trying to make my CCL code look almost exactly unlike
> that of the java-based processing.org.
...and then...
> I picked Lisp. Now I want to make Lisp look like 'processing'. That
> Sir, is no crime.
No, we call those contradictions. I will guess you meant the latter. At
pain of repeating myself, fine. So you aren't going to use DEFUN? Prefix
notation? Parentheses? Oh, you are? I see, some syntax is born more
equal than others.
You are embarked on a fine and interesting exercise. I see
processing.org is the soul brother of SDL, a longtime interest of yours.
I just think you misunderstand the Borg thing, which could lead to a
crappy result.
:)
kenny
--
Cells? Cello?: http://www.common-lisp.net/project/cells/
Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> (b) You are showing our age, Fred. Google reports that Luke dropped
Lisp
> Newbie Question #1 into c.l.l. on Jan 17, 2002. Only a dinosaur like
us
> would consider 3+ years a newbie.
My how time flies. I think that what wound Kenny up is that he feels I
should know better. Perhaps I should, but unlike most here on CLL, I
probably spend on average, less than an hour a week actually working
Lisp code.
>
> (c) Let the roast resume!
Ah Kenny, my eyebrows are hardly even singed. Erik Naggum would have
had a field day.
> Oh, gosh, I /did/ help him! A fine barbecue chef I would make,
serving
> live chickens.
Yes you did even though the packaging took me by surprise.
- Luke
Luke Crook wrote:
> Kenny Tilton wrote:
>
>>(b) You are showing our age, Fred. Google reports that Luke dropped
>
> Lisp
>
>>Newbie Question #1 into c.l.l. on Jan 17, 2002. Only a dinosaur like
>
> us
>
>>would consider 3+ years a newbie.
>
>
> My how time flies. I think that what wound Kenny up is that he feels I
> should know better. Perhaps I should, but unlike most here on CLL, I
> probably spend on average, less than an hour a week actually working
> Lisp code.
>
>
>>(c) Let the roast resume!
>
>
> Ah Kenny, my eyebrows are hardly even singed. Erik Naggum would have
> had a field day.
>
>
>>Oh, gosh, I /did/ help him! A fine barbecue chef I would make,
>
> serving
>
>>live chickens.
>
>
> Yes you did even though the packaging took me by surprise.
The other thing you missed is that Borging generally requires a little
effort from the Borger:
(in-package :cl-user)
(defmacro defc++ (fname (&rest args) &body body)
`(progn
,(unless (macro-function fname)
`(defmacro ,fname (&rest m-args)
(let ((oload (intern (format nil "~a~a" ',fname (length
m-args)))))
`(,oload ,@m-args))))
(defmethod ,(intern (format nil "~a~a" fname (length args))) ,args
,@body)))
(defclass image ()())
(defclass color ()
(
(r :accessor r :initarg :r)
(g :accessor g :initarg :g)
(b :accessor b :initarg :b)
(a :accessor a :initarg :a)))
(let ((bground nil))
(defc++ set-background ((background image))
(setf bground background))
(defc++ set-background ((r integer) (g integer) (b integer) (a integer))
(if (typep bground 'color)
(progn
(setf (r bground) r)
(setf (g bground) g)
(setf (b bground) b)
(setf (a bground) a))
(setf bground (make-instance 'color :r r :g g :b b :a a)))
bground)
(defc++ set-background ((r integer) (g integer) (b integer))
(set-background r g b 255))
(defun background ()
bground))
kenny
--
Cells? Cello?: http://www.common-lisp.net/project/cells/
Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> The other thing you missed is that Borging generally requires a
little
> effort from the Borger:
:) Thanks. This is why I really like Lisp.
-Luke
Luke J Crook wrote (from now on):
> It would be great if (BACKGROUND) returns
> the background, and (BACKGROUND image/r g b/r g b a) sets the
> background. As you pointed out this is not possible in Lisp - which is
> kind of weird, Lisp being the Borg of languages and all.
You have not yet reached enlightenment, Grasshopper.
First of all (BACKGROUND) seems to be missing a parameter, namely the
background of WHAT?
The Lisp paradigm approach to this would have
(background something) => return background
(setf (background something) new-background) => sets it.
This presumes that you follow the advice that I and others gave to
encapsulate the background descriptor into a single object. I'm
actually curious what you would expect (background) to return for the
case of RGB values. In lisp, of course, it could return multiple
values, but what about the other languages you seem to be familiar
with? What return value do you want?
Methinks you really want to have only a single object used in the
interface. That will really simplify your code when you don't have to
try to look at potential multiple return values to figure out what in
the world the code returns to you, but can instead use a simple TYPECASE
statement. (BTW the latter seems to be sadly lacking as a nice form in
most other languages....)
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Luke J Crook wrote (from now on):
>
>>It would be great if (BACKGROUND) returns
>>the background, and (BACKGROUND image/r g b/r g b a) sets the
>>background. As you pointed out this is not possible in Lisp - which is
>>kind of weird, Lisp being the Borg of languages and all.
>
>
> You have not yet reached enlightenment, Grasshopper.
>
> First of all (BACKGROUND) seems to be missing a parameter, namely the
> background of WHAT?
A closed-over binding shared by all the methods. Kinda strange, because
I would think there would be some window or other instance of which
background would be an attribute, the the rules of this game are...
>
> The Lisp paradigm approach to this would have
>
> (background something) => return background
> (setf (background something) new-background) => sets it.
>
> This presumes that you follow the advice that I and others gave to
> encapsulate the background descriptor into a single object. I'm
> actually curious what you would expect (background) to return for the
> case of RGB values. In lisp, of course, it could return multiple
> values, but what about the other languages you seem to be familiar
> with? What return value do you want?
>
> Methinks you really want to have only a single object used in the
> interface.
...to create something precisely identically as fucked up as the
Processing code. At that point the OP will be able to say... uh, not sure.
:)
kt
--
Cells? Cello?: http://www.common-lisp.net/project/cells/
Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> A closed-over binding shared by all the methods. Kinda strange,
because
> I would think there would be some window or other instance of which
> background would be an attribute, the the rules of this game are...
Well, SDL only supports a single window and I think of a background as
the video display surface, hence the syntax.
> ...to create something precisely identically as fucked up as the
> Processing code. At that point the OP will be able to say... uh, not
sure.
Sure.
- Luke
Luke Crook wrote:
> Kenny Tilton wrote:
>
>>A closed-over binding shared by all the methods. Kinda strange,
>
> because
>
>>I would think there would be some window or other instance of which
>>background would be an attribute, the the rules of this game are...
>
>
> Well, SDL only supports a single window and I think of a background as
> the video display surface, hence the syntax.
>
>
>>...to create something precisely identically as fucked up as the
>>Processing code. At that point the OP will be able to say... uh, not
>
> sure.
>
> Sure.
>
> - Luke
>
You did not like DEFC++?
kt
--
Cells? Cello?: http://www.common-lisp.net/project/cells/
Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Thomas A. Russ wrote:
> First of all (BACKGROUND) seems to be missing a parameter, namely the
> background of WHAT?
>
> The Lisp paradigm approach to this would have
>
> (background something) => return
background
> (setf (background something) new-background) => sets it.
I agree, however the graphics library I am using (SDL) only supports a
single window, so there really is only a single 'background' available.
I do a similar thing with my sprite engine. There is only ever a single
engine so adding a sprite, image or background to the engine means I:
(add <image>)
(add <sprite>)
(add (get-background))
I determine background type using draw methods:
(draw (background))
(draw <image>)
(draw <sprite>)
>
> This presumes that you follow the advice that I and others gave to
> encapsulate the background descriptor into a single object.
I have now done so, passing the following objects to (set-background
...
- (color 200 100 2),
- (color 50 50 50 255),
- (image :filename "test-image.bmp"),
- (sprite :id 'player :visible t :image <image>)
> I'm
> actually curious what you would expect (background) to return for the
> case of RGB values. In lisp, of course, it could return multiple
> values, but what about the other languages you seem to be familiar
> with? What return value do you want?
> Methinks you really want to have only a single object used in the
> interface. That will really simplify your code when you don't have
to
> try to look at potential multiple return values to figure out what in
> the world the code returns to you, but can instead use a simple
TYPECASE
> statement. (BTW the latter seems to be sadly lacking as a nice form
in
> most other languages....)
Whew, this I did do in my code. (background) returns whatever is stored
in 'bground', see below:
(let ((bground nil))
(defmethod set-background ((background image))
(setf bground background))
....
(defmethod background ()
bground))
As I discussed above, I use several methods that specialize on the
'bground' type.
(defmethod draw ((col color))
...)
(defmethod draw ((img image) &key (x 0) (y 0))
...)
So hopefully most of the suggestions I received from contributers to
this thread have sunk in.
Thank you all.
- Luke
On Tue, 9 May 2005, Luke Crook wrote:
> No, that dooes not give me the result I want.
>
> I want my code to look something like this:
>
> (set-background AN-IMAGE) ; Set background to a static image
> (set-background AN-ANIM) ; Set background to display a video
> (set-background 255 255 255) ; Set background to a single color of the
> format r g b
> (set-background 255 255 255 100) ; Set background to a single color
> with a transparency
> (set-background 100) ; Convert the specified 8-bit color to r g b with
> default 255 level transparenct
>
> Doing all of this with keywords defeats the point of having CLOS. And
> not being able to specify a parameter type means that all the code for
> determing the type needs to be in the method body.
Would it be an acceptable workaround to have the methods called like
this:
(set-background image)
(set-background animation)
(set-background (list r g b))
(set-background (list r g b a))
This way you could use CLOS for dispatching between others than the
two last ones; and I believe those will be similar enough that having
them handled in a single method body is not too bad.
If you really want C++ style overloading, then CLOS does not give it
to you. But if I understand the C++ thing correctly, it relies on the
compiler actually calling differently named functions for different
argument lists under the hood. I guess it would be simple to do the
same in lisp with macros, but I haven't been tempted to do it myself.
just my two cents,
-Mikko
Mikko Heikel� <········@cc.hut.fi> writes:
> On Tue, 9 May 2005, Luke Crook wrote:
>> No, that dooes not give me the result I want.
>>
>> I want my code to look something like this:
>>
>> (set-background AN-IMAGE) ; Set background to a static image
>> (set-background AN-ANIM) ; Set background to display a video
>> (set-background 255 255 255) ; Set background to a single color of the
>> format r g b
>> (set-background 255 255 255 100) ; Set background to a single color
>> with a transparency
>> (set-background 100) ; Convert the specified 8-bit color to r g b with
>> default 255 level transparenct
>>
>> Doing all of this with keywords defeats the point of having CLOS. And
>> not being able to specify a parameter type means that all the code for
>> determing the type needs to be in the method body.
>
> Would it be an acceptable workaround to have the methods called like
> this:
>
> (set-background image)
> (set-background animation)
> (set-background (list r g b))
> (set-background (list r g b a))
>
> This way you could use CLOS for dispatching between others than the
> two last ones; and I believe those will be similar enough that having
> them handled in a single method body is not too bad.
>
> If you really want C++ style overloading, then CLOS does not give it
> to you. But if I understand the C++ thing correctly, it relies on the
> compiler actually calling differently named functions for different
> argument lists under the hood. I guess it would be simple to do the
> same in lisp with macros, but I haven't been tempted to do it myself.
Indeed, see a recent thread about it.
http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/bb95aa8bc0fbc294/275f1fbd0325699f?q=group:comp.lang.lisp+author:Pascal+author:Bourguignon++defmacro++test-1&rnum=1&hl=en#275f1fbd0325699f
> just my two cents,
>
> -Mikko
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
Mikko Heikelä wrote:
> Would it be an acceptable workaround to have the methods called like
> this:
>
> (set-background image)
> (set-background animation)
> (set-background (list r g b))
> (set-background (list r g b a))
>
> This way you could use CLOS for dispatching between others than the
> two last ones; and I believe those will be similar enough that having
> them handled in a single method body is not too bad.
Yes. I've tried to take everyones suggestions to heart. I now have the
following methods:
(set-background image)
(set-background animation)
(set-background (color r g b))
(set-background (color r g b a))
(background)
- Luke
Luke Crook wrote:
> No, that dooes not give me the result I want.
>
> I want my code to look something like this:
>
> (set-background AN-IMAGE) ; Set background to a static image
> (set-background AN-ANIM) ; Set background to display a video
> (set-background 255 255 255) ; Set background to a single color of the
> format r g b
> (set-background 255 255 255 100) ; Set background to a single color
> with a transparency
> (set-background 100) ; Convert the specified 8-bit color to r g b with
> default 255 level transparenct
>
> Doing all of this with keywords defeats the point of having CLOS. And
> not being able to specify a parameter type means that all the code for
> determing the type needs to be in the method body.
Why does it defeat the point of having CLOS? Just because it does not
fit the C++/Java overloading model (which BTW, does not give you
multimethods) does not mean that things can be done dfferently.
First of all, what are you setting the background of? Let's suppose it
is of an IMAGE. A much better interface with much better names (since
they give away more information, would be
(defgeneric set-background (image what &key))
(defmethod set-background ((i1 image) (i2 image) &key) ...)
(defmethod set-background ((i image) (a animation) &key) ...)
(defmethod set-background ((i image) (c color) &key (transparency 100)) ...)
Now you want "spliced" methods
(defgeneric set-background* (image r g b &optional transparency))
;;; The '*' at the end is a CLIM convention if I remember correctly.
(defmethod set-background* ((i image) r g b &optional (transparency
100)) ...)
The interesting thing is that now you can do things like
(defmethod set-background ((s screen) (i image) &key) ...)
Getting the hang of it?
Cheers
--
Marco
>
> -Luke
>
Eric Lavigne wrote:
> I don't know CLOS yet, but I assume the syntax for methods is similar
> to the syntax for functions. You are allowed to make several versions
> of a method which take different types of parameters, but they all need
> to take the same number of parameters.
Indeed, as Graham writes: "Methods can have parameter lists ... but the
parameter lists ... must be congruent. They must have the same number
of required parameters, the same number of optional parameters (if any),
and must either all use &rest or &key, or all not use them." So
function overloading in the C++ style (like the OP probably attempted)
won't apply here.
mkb.
>They must have the same number of required parameters
This was my guess, but it doesn't match all of the OP's presented
evidence.
a) (set-background IMAGE) ; works
b) (set-background 100 100 100 255) ; works
c) (set-background 100 100 100) ; fails - "Wrong number of arguments"
Note that (a b) both work even though they have different numbers of
arguments. The conflict seems to be between (b c) only.
I'm beginning to think that (a) and (b) working may be a function of
the CL environment I am using (Corman Lisp).
Placing defmethods in order of increasing parameter lists is causing a
stack-overflow error.
"Luke Crook" <····@balooga.com> writes:
> Would someone be kind enough to explain the following...
>
> a) (set-background IMAGE) ; works
> b) (set-background 100 100 100 255) ; works
> c) (set-background 100 100 100) ; fails - "Wrong number of arguments"
I think you're trying to do things like in other languages such
as Java or C++. You should read about CLOS, for example in PCL:
http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html
http://www.gigamonkeys.com/book/object-reorientation-classes.html
Luke Crook wrote:
> Would someone be kind enough to explain the following...
>
> a) (set-background IMAGE) ; works
> b) (set-background 100 100 100 255) ; works
> c) (set-background 100 100 100) ; fails - "Wrong number of arguments"
Just change b to
(set-background (color 100 100 100 255))
an c to
(set-background (color 100 100 100))
and define the color function appropriately.
-- MJF
M Jared Finder <·····@hpalace.com> writes:
>
> Luke Crook wrote:
> > Would someone be kind enough to explain the following...
> >
> > a) (set-background IMAGE) ; works
> > b) (set-background 100 100 100 255) ; works
> > c) (set-background 100 100 100) ; fails - "Wrong number of arguments"
>
> Just change b to
>
> (set-background (color 100 100 100 255))
>
> an c to
>
> (set-background (color 100 100 100))
>
> and define the color function appropriately.
And this then also gives you a better design for future extensibility,
since you really want to have some object for the color specification.
That way you can have
(rgb-color 100 100 100)
and
(hsb-color 100 100 100)
and
(gray-scale 50)
or support for any other color model. You want the color descriptors to
be either classes themselves or defstruct structures.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> And this then also gives you a better design for future
extensibility,
> since you really want to have some object for the color
specification.
>
> That way you can have
>
> (rgb-color 100 100 100)
>
> and
>
> (hsb-color 100 100 100)
>
> and
>
> (gray-scale 50)
>
A couple of days ago I would have gone down the path of...
(set-background 100 50 100 :color-model 'HSB)
... which in retrospect seems messy.
I have since changed my code to reflect your suggestions.
-Luke
Luke Crook wrote:
> Would someone be kind enough to explain the following...
>
> a) (set-background IMAGE) ; works
> b) (set-background 100 100 100 255) ; works
> c) (set-background 100 100 100) ; fails - "Wrong number of arguments"
It's a bug that both a and b work. Some aspects of CLOS rely on the fact
that method dispatch is not based on the number of arguments, but only
on the specializers for the (fixed number of) required arguments.
If you want overloading, choose different names like
set-background-image and set-background-color and so forth. Since Lisp
has a prefix syntax, the burden of not having "real" overloading doesn't
really show. (You know that you want different functionality anyway, so
why do you try to lump different things together in the first place?)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Luke Crook wrote:
> > Would someone be kind enough to explain the following...
> > a) (set-background IMAGE) ; works
> > b) (set-background 100 100 100 255) ; works
> > c) (set-background 100 100 100) ; fails - "Wrong number of arguments"
>
> It's a bug that both a and b work. Some aspects of CLOS rely on the
> fact that method dispatch is not based on the number of arguments, but
> only on the specializers for the (fixed number of) required arguments.
>
> If you want overloading, choose different names like
> set-background-image and set-background-color and so forth. Since Lisp
> has a prefix syntax, the burden of not having "real" overloading
> doesn't really show. (You know that you want different functionality
> anyway, so why do you try to lump different things together in the
> first place?)
It would be convenient for arithmetic operators. + is the simplest example.
I'm currently thinking about a very simple, not necessarily very fast,
vector lib (to manipulate vectors of numbers of different type).
Having written similar stuff in C++ often enough the lack of
"static" overloading was the first "obstacle" I experienced.
Not being very proficient in CLOS I wonder if there's a rational for
this limitation? It seems like such a simple thing to allow. Ok,
you can always trade flexibility for speed/ better compilation but
this doesn't seem a major design goal behind CLOS, and using a macro a
potential performance penalty could probably be eliminated. Also, you
can claim "overloading is evil!" and try force programmers in your
philosophy, but this seem entirely un-lispy. So there must be a
technical reason? Or was it simply overlooked? Was static
overloading invented by C++?
Thanks,
Matthias
Matthias wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>Luke Crook wrote:
>>
>>>Would someone be kind enough to explain the following...
>>>a) (set-background IMAGE) ; works
>>>b) (set-background 100 100 100 255) ; works
>>>c) (set-background 100 100 100) ; fails - "Wrong number of arguments"
>>
>>It's a bug that both a and b work. Some aspects of CLOS rely on the
>>fact that method dispatch is not based on the number of arguments, but
>>only on the specializers for the (fixed number of) required arguments.
>>
>>If you want overloading, choose different names like
>>set-background-image and set-background-color and so forth. Since Lisp
>>has a prefix syntax, the burden of not having "real" overloading
>>doesn't really show. (You know that you want different functionality
>>anyway, so why do you try to lump different things together in the
>>first place?)
>
> It would be convenient for arithmetic operators. + is the simplest example.
>
> I'm currently thinking about a very simple, not necessarily very fast,
> vector lib (to manipulate vectors of numbers of different type).
> Having written similar stuff in C++ often enough the lack of
> "static" overloading was the first "obstacle" I experienced.
>
> Not being very proficient in CLOS I wonder if there's a rational for
> this limitation? It seems like such a simple thing to allow. Ok,
> you can always trade flexibility for speed/ better compilation but
> this doesn't seem a major design goal behind CLOS, and using a macro a
> potential performance penalty could probably be eliminated. Also, you
> can claim "overloading is evil!" and try force programmers in your
> philosophy, but this seem entirely un-lispy. So there must be a
> technical reason? Or was it simply overlooked? Was static
> overloading invented by C++?
I think efficiency is one of the major reasons. This allows method
dispatch to blindly get the specializers (classes) of a fixed number of
arguments and look up the methods in the method caches. If you do some
benchmarks with CLOS you will notice that generic functions are
generally _very_ fast, close to regular functions.
I think there would also be some semantic problems wrt deciding method
specificity (are optional arguments more specific than keyword
arguments? ;). But I haven't thought about this in detail.
I also find it very handy that it's so easy to replace the definition of
an existing method: Whenever you add a method, an old method that has
the same specializers and qualifiers is automatically removed
beforehand. This would also be harder to achieve, I guess.
In other words, you would have to make some compromises anyway...
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
On Tue, 10 May 2005 16:50:04 +0200, <··@p-cos.net> wrote:
> Matthias wrote:
>>
>> Not being very proficient in CLOS I wonder if there's a rational for
>> this limitation? It seems like such a simple thing to allow. Ok,
>> you can always trade flexibility for speed/ better compilation but
>> this doesn't seem a major design goal behind CLOS, and using a macro a
>> potential performance penalty could probably be eliminated. Also, you
>> can claim "overloading is evil!" and try force programmers in your
>> philosophy, but this seem entirely un-lispy. So there must be a
>> technical reason? Or was it simply overlooked? Was static
>> overloading invented by C++?
>
> I think efficiency is one of the major reasons. This allows method
> dispatch to blindly get the specializers (classes) of a fixed number of
> arguments and look up the methods in the method caches. If you do some
> benchmarks with CLOS you will notice that generic functions are
> generally _very_ fast, close to regular functions.
I find it a compelling reason. I'm about a quarter way thru S. Keene
CLOS book, and I was wondering if all this baggage (of CLOS) was worth
it. Then I read the above statement in Keene, and knew that it was
worth it, since I wasn't giving up speed after all.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.