I come from OO programming. I'm new to lisp but i wanna learn it.
My question is: since I'm good (or not too bad) in OOP can I start
directly with CLOS or rather have I to learn lisp basis ? Do you think
it is difficult the step from java to clos?
the only thing i learnt is that, in CLOS, methods don't belong to
classe or instances, they are independent and i think i could be an
advantage.
Thanks
Regards
-c.
I think you'll be OK with an approach where you focus on CLOS and learn
Just Enough Lisp to get by.
Java -> CLOS should be easy. I see you know about generic functions.
That is different but unsurprising. :around, :before and :after are
intuitive. different method combinations are fun.
Speaking of generic functions, I heard somewhere Java was adding GFs to
the spec...true that?
kenny
clinisys
Rocchi Cesare wrote:
>
> I come from OO programming. I'm new to lisp but i wanna learn it.
> My question is: since I'm good (or not too bad) in OOP can I start
> directly with CLOS or rather have I to learn lisp basis ? Do you think
> it is difficult the step from java to clos?
> the only thing i learnt is that, in CLOS, methods don't belong to
> classe or instances, they are independent and i think i could be an
> advantage.
>
> Thanks
>
> Regards
>
> -c.
Hello!
In article <·················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
>Speaking of generic functions, I heard somewhere Java was adding GFs to
>the spec...true that?
AFAIK, there is at least some extension for Java, under the "AOP"
buzzword to add method combination like features to Java.
Kind regards,
Hannah.
Hannah Schroeter wrote:
>
> Hello!
>
> In article <·················@nyc.rr.com>,
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
> >Speaking of generic functions, I heard somewhere Java was adding GFs to
> >the spec...true that?
>
> AFAIK, there is at least some extension for Java, under the "AOP"
> buzzword to add method combination like features to Java.
>
> Kind regards,
>
> Hannah.
There is also the "Generic Java" and "Pizza" efforts from
http://cm.bell-labs.com/cm/cs/who/wadler/gj/ and
http://cm.bell-labs.com/cm/cs/who/wadler/pizza.
There are other sites for this stuff, but this is where it all started.
Eric
--
US Supreme Court hearing 00-836
GEORGE W. BUSH, Petitioner, v. PALM BEACH COUNTY CANVASSING BOARD
Justice (Scalia?) to Mr. Klock (representing Katherine Harris):
20 and therefore, I guess, whether we win, whether your side,
21 the side you're supporting wins or loses, it doesn't
22 change that, and I guess that's moot, but my question is,
> There is also the "Generic Java" and "Pizza" efforts from
> http://cm.bell-labs.com/cm/cs/who/wadler/gj/ and
> http://cm.bell-labs.com/cm/cs/who/wadler/pizza.
oops--these are for generic types, not generic functions. My bad.
Eric
Kenny Tilton wrote:
> Speaking of generic functions, I heard somewhere Java was adding GFs to
> the spec...true that?
If you are talking about Wadler's work on GJ (Generic Java), what he means
by "generic" is actually the equivalent of C++ templates. See his web
page: http://cm.bell-labs.com/cm/cs/who/wadler/topics/gj.html. The article
in the 1999 OOPSLA (now known as The Conference on How to do Things With
Java) Proceedings is a good introduction.
faa
"Frank A. Adrian" wrote:
>
> Kenny Tilton wrote:
> > Speaking of generic functions, I heard somewhere Java was adding GFs to
> > the spec...true that?
>
> If you are talking about Wadler's work on GJ (Generic Java), what he means
> by "generic" is actually the equivalent of C++ templates.
ok, i do not know what i am talkign about. to be honest, some other
roller bladers in the park said something about Java and I tried to
start a flame war by taunting them with Lisp, but they both said they
liked Lisp and one guy said Java was adding GFs and macros. woo-hoo! I
thought.
but templates?!!! yechh
kenny
clinisys
* ········@libero.it (Rocchi Cesare)
> I come from OO programming. I'm new to lisp but i wanna learn it.
> My question is: since I'm good (or not too bad) in OOP can I start
> directly with CLOS or rather have I to learn lisp basis ?
CLOS _is_ Lisp, so when you study CLOS, you study Lisp. Unless read 20
years of Lisp literature chronologically, you'll hardly notice that CLOS
once was an optional extension to Lisp.
You really should learn the basics of Common Lisp before moving on to
classes, generic functions and methods, but there are lots of advanced
topics you don't have to be an expert in to get started, e g macros,
conditions, files and pretty printing.
Erik
* Erik Haugan <····@haugan.no>
| CLOS _is_ Lisp, so when you study CLOS, you study Lisp.
I think this is one of those situations where it is important to point
out that CLOS is _Common_ Lisp. Although no other Lisps are relevant in
the third millennium :), I would be cautious about those highlighted "is"
relationships. Much can go seriously wrong if you believe in bad ones.
| You really should learn the basics of Common Lisp before moving on to
| classes, generic functions and methods, but there are lots of advanced
| topics you don't have to be an expert in to get started, e g macros,
| conditions, files and pretty printing.
This is good advice.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
Erik Naggum <····@naggum.net> writes:
> I think this is one of those situations where it is important to
> point out that CLOS is _Common_ Lisp. Although no other Lisps are
> relevant in the third millennium :)
You don't consider emacs-lisp a lisp? (or perhaps you don't consider
it relevant, which I'd find surprising).
--
* Erik Naggum
> I think this is one of those situations where it is important to
> point out that CLOS is _Common_ Lisp. Although no other Lisps are
> relevant in the third millennium :)
* Robert Pluim
| You don't consider emacs-lisp a lisp? (or perhaps you don't consider
| it relevant, which I'd find surprising).
I consider the statement I made somewhat sarcastic or perhaps sardonic.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
Erik Naggum <····@naggum.net> writes:
> * Erik Naggum
> > I think this is one of those situations where it is important to
> > point out that CLOS is _Common_ Lisp. Although no other Lisps are
> > relevant in the third millennium :)
>
>
> * Robert Pluim
> | You don't consider emacs-lisp a lisp? (or perhaps you don't consider
> | it relevant, which I'd find surprising).
>
> I consider the statement I made somewhat sarcastic or perhaps
> sardonic.
Whilst I considered my statement to be (slightly) humourous. I'll be
more heavy-handed next time ;-)
--
* Erik Naggum <····@naggum.net>
> I think this is one of those situations where it is important to point
> out that CLOS is _Common_ Lisp.
Granted. I was aware of it, but wanted to use the original posters own
words.
Erik
········@libero.it (Rocchi Cesare) writes:
> I come from OO programming. I'm new to lisp but i wanna learn it.
> My question is: since I'm good (or not too bad) in OOP can I start
> directly with CLOS or rather have I to learn lisp basis ? Do you think
> it is difficult the step from java to clos?
> the only thing i learnt is that, in CLOS, methods don't belong to
> classe or instances, they are independent and i think i could be an
> advantage.
Well, you should read the spec on CLOS and see what you think. It's
very different than Java, not just in the ways you cite. Java uses
dynamic method dispatch on the pre-dot stuff, so foo.bar(x,y) looks at the
dynamic class of foo, but Java use static dispatch on other args (x and y).
Lisp always uses dynamic dispatch. Java does its module boundaries on
the class boundary; Lisp uses packages. There are lot of differences really.
Free your mind before you dive in--what you know will be as much a hindrance
as a help. You might want to look for Sonya Keene's book to help you.
It goes through CLOS in a lot of detail and may be helpful to someone making
the transition.
CLOS and Common Lisp are the same, by the way. CLOS is just the object
system part of CLOS. You can't really program CLOS without knowing the
language that surrounds it. CLOS has no basic concepts like conditionals,
for example, that you will need in order to program.
The Common Lisp spec, including CLOS, can be found at:
http://www.xanalys.com/software_tools/reference/HyperSpec/FrontMatter/
········@libero.it (Rocchi Cesare) writes:
>I come from OO programming. I'm new to lisp but i wanna learn it.
>My question is: since I'm good (or not too bad) in OOP can I start
>directly with CLOS or rather have I to learn lisp basis ? Do you think
>it is difficult the step from java to clos?
>the only thing i learnt is that, in CLOS, methods don't belong to
>classe or instances, they are independent and i think i could be an
>advantage.
Well, I think it might be easier for you to start with CLOS and then
if you see fit drop it and do most stuff without CLOS.
Take in mind that CLOS is a huge-overhead mechanism, you cannot
objectise things on a scale you would in other OO languages. It is an
entirely different tool. Some people, me amoung them, don't have a
need for CLOS at all. And that is not because I dish OO in principle,
it's just that the number of other Lisp tools is sufficient for my
needs and better for some of my requirement.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
········@counter.bik-gmbh.de (Martin Cracauer) wrote in message news:<·············@counter.bik-gmbh.de>...
>
> Take in mind that CLOS is a huge-overhead mechanism, you cannot
> objectise things on a scale you would in other OO languages. It is an
> entirely different tool. Some people, me amoung them, don't have a
> need for CLOS at all. And that is not because I dish OO in principle,
> it's just that the number of other Lisp tools is sufficient for my
> needs and better for some of my requirement.
I think this is really misleading. CLOS is completely integrated into
the language and it's very hard to write significant modern CL
programs without using it. For instance the condition system is
(almost certainly) CLOS based - I put `almost certainly' there because
I'm not *sure* if it has to be formally, though I think it does, but
it's certainly hard to see an implementation which isn't - so if you
define or signal conditions you are using CLOS. Some implementations
have pre-CLOS condition systems, but unless these inmplement enough to
really look like a CLOS-based one they're really a pain - for instance
you really *want* multiple-inheritance so you can do things like
(define-condition my-program-condition ()
...)
(define-condition my-program-error (my-program-condition error)
...)
(define-condition my-program-simple-error (my-program-error
simple-error)
...)
so you can ensure that all conditions signalled by your program are
subclasses of one condition class - which is important so, for
instance, you can handle your conditions but allow others
(representing unexpected bugs) to drop into the debugger - while not
having to reimplement the whole mechanism of simple-errors in the way
you'd have to with Java or something.
There are at least two ways of defining classes with inheritance in
Lisp: structures provide a fast, low-overhead mechanism with
single-inheritance (basically like Java), while things defined with
DEFCLASS provide multiple-inheritance, initialisation ctonrol, and
lots of other features, with probably higher overhead. You can define
methods on both these types of thing. I guess you could consider
structures `huge overhead' and program in Lisp 1.5 or something.
You can also define methods specialising on predefined classes like
STRING and INTEGER. I do this really all the time.
I guess you could obsess about method-dispatch overhead and insist on
writing your own type-dispatching code. Every time I've tried to do
this I've found that the code I wrote was slower than what CLOS gave
me, or insignificantly faster.
--tim
> ········@counter.bik-gmbh.de (Martin Cracauer) wrote in message news:<·············@counter.bik-gmbh.de>...
> >
> > Take in mind that CLOS is a huge-overhead mechanism, you cannot
> > objectise things on a scale you would in other OO languages. It is an
> > entirely different tool. Some people, me amoung them, don't have a
> > need for CLOS at all. And that is not because I dish OO in principle,
> > it's just that the number of other Lisp tools is sufficient for my
> > needs and better for some of my requirement.
Oh for crying out loud, the OP is coming from Java. This probably
means that he probably isn't hung up on losing a cycle here or there
for felxibility. I don't know what huge overhead you're referring to,
but near as I can figure, it'd be dynamic dispatch. Well, sure, it's
slower than non-virtual methods in C++, but Java's all dynamic
(there). I just don't see anything that would force anyone to use OOP
any less than most other OO languages. Short of control structures
(and even some of them can), what can't be reasonably done in an OO
style?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@conquest.OCF.Berkeley.EDU>...
> Java's all dynamic
> (there).
Doesn't java do this weird static thing based on declared-type on
non-first arguments? I forget the syntax but something like
foo.bar(x,y), which in Lisp mught be (bar foo x y) is dynamic on the
foo but can further `dispatch' on the *declared* type of x and y.
I'm now going to embarras myself further by wondering whether that was
*all* the first C++ systems did, I seem to remember it was but it's a
very long time since I used C++ (practically since those first C++
systems in fact, trying to get a version of cfront of dubious legality
to compile...)
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@conquest.OCF.Berkeley.EDU>...
> > Java's all dynamic
> > (there).
>
> Doesn't java do this weird static thing based on declared-type on
> non-first arguments? I forget the syntax but something like
> foo.bar(x,y), which in Lisp mught be (bar foo x y) is dynamic on the
> foo but can further `dispatch' on the *declared* type of x and y.
That's correct. Methods with the same same and (approximate) signature
that differ based on run-time types are said to be overridden, while
methods that differ based on declared types are overloaded.
Using a hybrid pseudo-cody form:
Class1::doSomething (int x, int y);
and
Class2::doSomething (int x, int y);
is an example of overriding--the executed method will be determined
based on run-time types
Class1::doSomething (int x, int y);
and
Class1::doSomething (float x, int y);
is overloading--the executed method will be determined at compile-time
by the declared types.
Thom
--
Thom Goodsell ·········@cra.com
Scientist (617) 491-3474 x574
Charles River Analytics http://www.cra.com/
··········@tfeb.org (Tim Bradshaw) writes:
> I'm now going to embarras myself further by wondering whether that was
> *all* the first C++ systems did, I seem to remember it was but it's a
> very long time since I used C++ (practically since those first C++
> systems in fact, trying to get a version of cfront of dubious legality
> to compile...)
I don't know about early C++, but for current C++, foo->bar(x, y)
will, if bar is a virtual (dynamic-dispatch) method, dispatch on the
dynamic type of foo, and the declared types of x and y. Yick.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 28 Nov 2001 05:28:11 -0800, ··········@tfeb.org (Tim Bradshaw) said:
Tim> Doesn't java do this weird static thing based on declared-type on
Tim> non-first arguments? I forget the syntax but something like
Tim> foo.bar(x,y),
Yes, this is the syntax.
Tim> which in Lisp mught be (bar foo x y) is dynamic on the
Tim> foo but can further `dispatch' on the *declared* type of x and y.
Well, if x is an object, it must be an instance of either the
declared class or a subclass (ditto for y), but that class would be
used for the dispatch. Maybe you are thinking about the
(so-called) static methods: if bar() was static, then it would
dispatch on foo's declared class. FWIW.
---Vassil.
Vassil Nikolov <········@poboxes.com> wrote in message news:<·············@eskimo.com>...
> Well, if x is an object, it must be an instance of either the
> declared class or a subclass (ditto for y), but that class would be
> used for the dispatch. Maybe you are thinking about the
> (so-called) static methods: if bar() was static, then it would
> dispatch on foo's declared class. FWIW.
are you saying that in a call like
bar.foo(x,y)
there is full, dynamic dispatch on the class of x and y as well as that of foo?
--tim
On 29 Nov 2001 05:10:31 -0800, ··········@tfeb.org (Tim Bradshaw) said:
Tim> Vassil Nikolov <········@poboxes.com> wrote in message news:<·············@eskimo.com>...
Vassil> Well, if x is an object, it must be an instance of either the
Vassil> declared class or a subclass (ditto for y), but that class would be
Vassil> used for the dispatch. Maybe you are thinking about the
Vassil> (so-called) static methods: if bar() was static, then it would
Vassil> dispatch on foo's declared class. FWIW.
Tim> are you saying that in a call like
Tim> bar.foo(x,y)
(``foo.bar(x, y)'', of course)
Tim> there is full, dynamic dispatch on the class of x and y as well as that of foo?
You are right, I have to correct myself. In my first sentence
above, it is ambiguous to what `that class' refers and perhaps the
more natural interpretation is that it refers to the subclass,
which makes the statement wrong. (The method signature is
determined at compile time indeed.) I guess I was subconsciously
thinking what was weird about that and what else would be weirder
(like static method lookup in my mind). Should have been more
careful around midnight.
---Vassil.
Tim Bradshaw wrote:
> Vassil Nikolov <········@poboxes.com> wrote in message
> news:<·············@eskimo.com>...
>> Well, if x is an object, it must be an instance of either the
>> declared class or a subclass (ditto for y), but that class would be
>> used for the dispatch. Maybe you are thinking about the
>> (so-called) static methods: if bar() was static, then it would
>> dispatch on foo's declared class. FWIW.
>
> are you saying that in a call like
>
> bar.foo(x,y)
>
> there is full, dynamic dispatch on the class of x and y as well as that of
> foo?
It depends on what "bar" and "foo" actually are. If bar is an instance
variable of a class "A" like:
A bar;
then bar.foo() is not dynamic dispatch.
If you want to have dynamic dispatch you have to ensure that "bar" is
either a reference variable or a pointer to an instance of A.
// as reference to instance
A& bar; // would be an error since references have to be bound on
// initialization
// as pointer to instance
A* bar;
Additionally you have to make sure that "foo" is declared "virtual" in the
class definition (which is not the default):
class A {
public:
virtual void foo () {};
};
The last thing to note is that you only can write bar.foo() if you have a
reference and have to write bar->foo() if you have a pointer to the
instance.
References were a later add-on to C++.
C++ does never do dynamic dispatch on any of it's method arguments (the
implicit "this" argument explicitely not counted ;-) )
ciao,
Jochen
--
http://www.dataheaven.de
* ··········@tfeb.org (Tim Bradshaw) wrote:
|
| Vassil Nikolov <········@poboxes.com> wrote in message news:<·············@eskimo.com>...
| > Well, if x is an object, it must be an instance of either the
| > declared class or a subclass (ditto for y), but that class would be
| > used for the dispatch. Maybe you are thinking about the
| > (so-called) static methods: if bar() was static, then it would
| > dispatch on foo's declared class. FWIW.
|
| are you saying that in a call like
|
| bar.foo(x,y)
|
| there is full, dynamic dispatch on the class of x and y as well as that of foo?
If Vassil meant that, then he is wrong.
class A { public: virtual int foo(C* c) { return c->bar(); } };
class B : public A { public: virtual int foo(C* c) { return c->bar() + c->bar(); } };
class C { public: virtual int bar() { return 1; } };
class D : public C { public: virtual int bar() { return 100; } };
int main()
{
A* a1 = new A();
A* a2 = new B();
C* c1 = new C();
C* c2 = new D();
printf("a1(c1): %d\n", a1->foo(c1));
printf("a1(c2): %d\n", a1->foo(c2));
printf("a2(c1): %d\n", a2->foo(c1));
printf("a2(c2): %d\n", a2->foo(c2));
return 0;
}
Barring syntax errors, the above will print (in C++, and, with the
syntax adjusted, in Java):
a1(c1): 1
a1(c2): 1
a2(c1): 2
a2(c2): 2
Whereas with full dynamic dispatch it would print:
a1(c1): 1
a1(c2): 100
a2(c1): 2
a2(c2): 200
Boris
--
·····@uncommon-sense.net - <http://www.uncommon-sense.net/>
"It's like deja vu all over again." -- Yogi Berra
Boris Schaefer <·····@uncommon-sense.net> writes:
> If Vassil meant that, then he is wrong.
>
> class A { public: virtual int foo(C* c) { return c->bar(); } };
> class B : public A { public: virtual int foo(C* c) { return c->bar() + c->bar(); } };
>
> class C { public: virtual int bar() { return 1; } };
> class D : public C { public: virtual int bar() { return 100; } };
>
> int main()
> {
> A* a1 = new A();
> A* a2 = new B();
> C* c1 = new C();
> C* c2 = new D();
>
> printf("a1(c1): %d\n", a1->foo(c1));
> printf("a1(c2): %d\n", a1->foo(c2));
> printf("a2(c1): %d\n", a2->foo(c1));
> printf("a2(c2): %d\n", a2->foo(c2));
>
> return 0;
> }
>
> Barring syntax errors, the above will print (in C++, and, with the
> syntax adjusted, in Java):
>
> a1(c1): 1
> a1(c2): 1
> a2(c1): 2
> a2(c2): 2
This is would only be the result if the member functions in C and D
where not declared virtual.
>
> Whereas with full dynamic dispatch it would print:
>
> a1(c1): 1
> a1(c2): 100
> a2(c1): 2
> a2(c2): 200
This is the result that the above snippet (with minor corrections) would give.
For the interested, try
//-cut-here------------
#include <iostream>
class C { public: virtual int bar() { return 1; } };
class D : public C { public: virtual int bar() { return 100; } };
class A { public: virtual int foo(C* c) { return c->bar(); } };
class B : public A { public: virtual int foo(C* c) { return c->bar() + c->bar(); } };
int main()
{
A* a1 = new A();
A* a2 = new B();
C* c1 = new C();
C* c2 = new D();
std::cout<<a1->foo(c1)<<std::endl;
std::cout<<a1->foo(c2)<<std::endl;
std::cout<<a2->foo(c1)<<std::endl;
std::cout<<a2->foo(c2)<<std::endl;
return 0;
}
//-cut-here------------
Vic
··········@tfeb.org (Tim Bradshaw) writes:
>········@counter.bik-gmbh.de (Martin Cracauer) wrote in message news:<·············@counter.bik-gmbh.de>...
>>
>> Take in mind that CLOS is a huge-overhead mechanism, you cannot
>> objectise things on a scale you would in other OO languages. It is an
>> entirely different tool. Some people, me amoung them, don't have a
>> need for CLOS at all. And that is not because I dish OO in principle,
>> it's just that the number of other Lisp tools is sufficient for my
>> needs and better for some of my requirement.
>I think this is really misleading. CLOS is completely integrated into
>the language and it's very hard to write significant modern CL
>programs without using it. For instance the condition system is
>(almost certainly) CLOS based - I put `almost certainly' there because
>I'm not *sure* if it has to be formally, though I think it does, but
>it's certainly hard to see an implementation which isn't - so if you
>define or signal conditions you are using CLOS.
No doubt. I was just pointing out that when designing your own code
-which may depend on speed- must (on every language) take the overhead
of function calls and data representation into account. CLOS has a
vastly different threshold in this regard and beginners have to know
that, otherwise we will end up with new Lispers complaining about
speed, although they didn't actually were ignorant and they used a
good compiler.
As another poster pointed out, the guy is coming from Java, but if you
are writing quite basic numeric classes in CLOS, you can actually end
up with a Common Lisp program that runs even slower than a Java
program. We don't want that happen to him :-)
CMUCL doesn't use its CLOS for the condition system, but this isn't by
design, so your point is technically valid.
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Martin Cracauer wrote:
>
> ··········@tfeb.org (Tim Bradshaw) writes:
>
> >········@counter.bik-gmbh.de (Martin Cracauer) wrote in message news:<·············@counter.bik-gmbh.de>...
> >>
> >> Take in mind that CLOS is a huge-overhead mechanism, you cannot
> >> objectise things on a scale you would in other OO languages. It is an
....
>
> No doubt. I was just pointing out that when designing your own code
> -which may depend on speed- must (on every language) take the overhead
> of function calls and data representation into account. CLOS has a
> vastly different threshold in this regard and beginners have to know
> that,
First of all, I do think about GFs vs defun in terms of speed, but it is
hardly something to worry /beginners/ about. That came later.
Second... huge? vast? Not sure how those units convert to percent, but
my perhaps poorly-conceived benchmarks came up with something between
20-25%.
(defun sqfn (n) (sqrt n))
(defun sqfntypep (n) (when (typep n 'number) (sqrt n)))
(defmethod sqgf ((n number)) (sqrt n))
(defmethod sqgf ((n string)) )
(defmethod sqgf ((n null)) )
(defmethod sqgf ((n vector)) )
(defmethod sqgf ((n (eql 42))) )
(defun testgf (n)
(time (dotimes (x n) (sqfn 42)))
(time (dotimes (x n) (sqgf 43)))
(time (dotimes (x n) (sqfntypep 42)))
)
(testgf 100000)
#|
; 0 cons cells, 0 symbols, -32 other bytes, 0 static bytes
; cpu time (non-gc) 321 msec user, 0 msec system
; cpu time (gc) 110 msec user, 0 msec system
; cpu time (total) 431 msec user, 0 msec system
; real time 431 msec
; space allocation:
; 0 cons cells, 0 symbols, 6,399,968 other bytes, 0 static bytes
; cpu time (non-gc) 390 msec user, 0 msec system
; cpu time (gc) 100 msec user, 0 msec system
; cpu time (total) 490 msec user, 0 msec system
; real time 490 msec
; space allocation:
; 0 cons cells, 0 symbols, 6,399,968 other bytes, 0 static bytes
; cpu time (non-gc) 331 msec user, 0 msec system
; cpu time (gc) 80 msec user, 0 msec system
; cpu time (total) 411 msec user, 0 msec system
; real time 411 msec
; space allocation:
; 5 cons cells, 0 symbols, 6,400,064 other bytes, 0 static bytes
I had to change the test of sqgf to 43 because the eql specialization on
42 was nicely optimized and ran in 20msec.
kenny
clinisys
Sorry, this makes more sense:
(defun sqfn (n) (sqrt n))
(defun sqfntypep (n) (when (typep n 'number) (sqrt n)))
(defmethod sqgf ((n number)) (sqrt n))
(defmethod sqgf ((n string)) )
(defmethod sqgf ((n null)) )
(defmethod sqgf ((n vector)) )
(defmethod sqgf ((n (eql 42))) )
(defun testgf (n)
(time (dotimes (x n) (sqrt x)))
(time (dotimes (x n) (sqfn x)))
(time (dotimes (x n) (sqgf x)))
(time (dotimes (x n) (sqfntypep x)))
)
(testgf 100000)
#|
; cpu time (non-gc) 321 msec user, 0 msec system
; cpu time (gc) 100 msec user, 0 msec system
; cpu time (total) 421 msec user, 0 msec system
; real time 421 msec
; space allocation:
; 5 cons cells, 0 symbols, 6,399,968 other bytes, 0 static bytes
; cpu time (non-gc) 321 msec user, 0 msec system
; cpu time (gc) 100 msec user, 0 msec system
; cpu time (total) 421 msec user, 0 msec system
; real time 421 msec
; space allocation:
; 0 cons cells, 0 symbols, 6,399,968 other bytes, 0 static bytes
; cpu time (non-gc) 400 msec user, 0 msec system
; cpu time (gc) 90 msec user, 0 msec system
; cpu time (total) 490 msec user, 0 msec system
; real time 490 msec
; space allocation:
; 0 cons cells, 0 symbols, 6,399,904 other bytes, 0 static bytes
; cpu time (non-gc) 331 msec user, 0 msec system
; cpu time (gc) 90 msec user, 0 msec system
; cpu time (total) 421 msec user, 0 msec system
; real time 421 msec
; space allocation:
; 0 cons cells, 0 symbols, 6,399,968 other bytes, 0 static bytes
NIL
Now I admit saying 25% is as wrong as saying "vast" or "huge", because
one could argue that the 100k invocations of the GF took 79msec (vs the
control which called sqrt directly) to the defun zero msec, and so it is
indeed vast aka infinite.
But functions generally do do some work, so... how to measure? perhaps
by the absolute amount: (/ 79msec 100k) or .00000079 sec per call.
except then how to assess that, since a busy app can quickly make a vast
number of calls? I think the answer is to stick with my goof and leave
some beef inside the function being invoked to give some perspective.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Now I admit saying 25% is as wrong as saying "vast" or "huge", because
> one could argue that the 100k invocations of the GF took 79msec (vs the
> control which called sqrt directly) to the defun zero msec, and so it is
> indeed vast aka infinite.
>
> But functions generally do do some work, so... how to measure? perhaps
> by the absolute amount: (/ 79msec 100k) or .00000079 sec per call.
> except then how to assess that, since a busy app can quickly make a vast
> number of calls? I think the answer is to stick with my goof and leave
> some beef inside the function being invoked to give some perspective.
FWIW, last time I ran low-level benchmarks of this sort, for CMU CL
18c on an AMD K6-2/550 a call to a GF with one unspecialized default
method took around 160ns, whereas the call to a normal function takes
around 60ns. That's a factor of around 2.8. If that kind of overhead
is significant, you probably want to elide the function call overhead
completely, and use either inlined functions or compiler-macros.
I think a more compelling argument to not use GFs and standard-objects
for some things is that they often don't add anything but a false
promise of extensibility, where none has been designed in. Use the
tool that is best suited to the task at hand, etc.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Rocchi Cesare" <········@libero.it> wrote in message
·································@posting.google.com...
> I come from OO programming. I'm new to lisp but i wanna learn it.
> My question is: since I'm good (or not too bad) in OOP can I start
> directly with CLOS or rather have I to learn lisp basis ? Do you think
> it is difficult the step from java to clos?
> the only thing i learnt is that, in CLOS, methods don't belong to
> classe or instances, they are independent and i think i could be an
> advantage.
>
For me I make almost no distinction between CLOS and LISP. Maybe this makes me
a bad man. CLOS is just another part of lisp, use it when it is the Right
Thing.
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
Opinion:
I would never suggest anyone jump straight into C++ without some
knowledge of the fundamentals of C (actually, I wouldn't suggest C++ at
all these days!) Java does not have pointers, macros, and explicit memory
management, so it is not too difficult to learn (though threads can be a
bit strange). Lisp is somewhere in between: I would suggest learning the
power of lists, vectors, arrays, macros, data structures, and streams
before jumping into the CLOS world.
sl
Rocchi Cesare wrote:
> I come from OO programming. I'm new to lisp but i wanna learn it.
> My question is: since I'm good (or not too bad) in OOP can I start
> directly with CLOS or rather have I to learn lisp basis ? Do you think
> it is difficult the step from java to clos?
> the only thing i learnt is that, in CLOS, methods don't belong to
> classe or instances, they are independent and i think i could be an
> advantage.
>
> Thanks
>
> Regards
>
> -c.
Steve Long <·········@isomedia.com> writes:
> I would never suggest anyone jump straight into C++ without some
> knowledge of the fundamentals of C (actually, I wouldn't suggest C++ at
> all these days!) Java does not have pointers, macros, and explicit memory
> management, so it is not too difficult to learn (though threads can be a
> bit strange). Lisp is somewhere in between: I would suggest learning the
> power of lists, vectors, arrays, macros, data structures, and streams
> before jumping into the CLOS world.
A common belief within the C++ community is that a knowledge of C is not
beneifical, and in some ways detrimental. Other than the common syntax
(and some of the c std library), there is little to learn from C that
would be beneficial to learning C++. The idioms are so far apart, true
C++ allows you to write C style, but why bother (there are reasons, most
do not apply to a newbie to C and C++ who is not involved with maintaining
existing code).
While I'm on my soap box. C++ is a nice language to learn and more
importantly, there are (nowadays) some very good books for learning C++.
The same can not be said about Java. Java does have pointers, they're
called references, the most common err in Java is an uninitialsed
reference. Java is a very useful language though.
However, I too am new to lisp and was wondering the same as the op, and
will take your advice and concentrate my initial efforts on non CLOS
lisp aspects.
Thanks,
Vic