Followup-To:
In article <···············@hurricane.OCF.Berkeley.EDU>, Thomas F. Burdick
wrote:
>And, for that matter, neither is CLISP. It is *heavily* deficient in
>the CLOS department. If you're not dealing with very OO code, it's
>fine; but if you are, you'll quickly find how very far it is from
>being an ANSI CL.
I've heard this on several occasions; I've not learned much about CLOS yet, but
can someone point me to information on how much (or little) of CLOS Clisp does
implement? I've been using Clisp for a while now, and I'm growing pretty
comfortable with it, but I'd like to know its strengths and weaknesses...
Thanks,
Bruce H. Nagel
"If you were plowing a field, which would you rather use? Two strong oxen
or 1024 chickens?"
-- Seymour Cray
········@Bast.debian.org (bruce) writes:
> In article <···············@hurricane.OCF.Berkeley.EDU>, Thomas F. Burdick
> wrote:
>
> >And, for that matter, neither is CLISP. It is *heavily* deficient in
> >the CLOS department. If you're not dealing with very OO code, it's
> >fine; but if you are, you'll quickly find how very far it is from
> >being an ANSI CL.
>
> I've heard this on several occasions; I've not learned much about CLOS yet, but
> can someone point me to information on how much (or little) of CLOS Clisp does
> implement? I've been using Clisp for a while now, and I'm growing pretty
> comfortable with it, but I'd like to know its strengths and weaknesses...
To get an idea, browse through the Types and Classes chapter of the
implementation notes: <http://clisp.sf.net/impnotes/types-classes.html>
The worst lowlights: you cannot redefine classes; you can only use the
STANDARD method combination.
One of the big highlights of CLOS is that you can redefine classes on
the fly, and the objects created under the old definition are still
usable -- it comes complete with a protocol for intervening in the
process: the UPDATE-INSTANCE-FOR-REDEFINED-CLASS generic function.
If you've worked in the Java world, maybe you've heard some hype about
"Aspect-Oriented Programming". Essentially, it lets you do more
powerful refactoring. 80% of what an aspect system can do falls under
normal, vanilla use of CLOS method combinations (the other 20%
involves using the MOP, which CLISP doesn't implement[*]). Most of
the time, you're fine with STANDARD method combination -- but when you
want other method combinations, it's so you can refactor your code in
interesting ways. Without this ability, you end out with the same
crappy, brittle, messy code that Java programmers got so upset about
that some of them are using nonstandard dialects like AspectJ.
Now, if you don't normally write OO code, this is irrelevant. But if
you want to learn OOP in Lisp, switch implementations. You can't
write good OO code in CLISP -- you get 80% nice code with 20% ugly
mess hacking around its deficiencies. And worse, if you didn't
already know how to use CLOS well, you might just restrict your
thinking to CLISP's subset, and spread the mess evenly throughout the
code.
[*] The MOP is really, really, really useful when you need it, but
it's not in the ANSI standard. If CLISP actually implemented CLOS as
specified by ANSI, and had no MOP, I wouldn't be hating. But if you
like OOP, the claim that CLISP is ANSI, or "almost ANSI" is laughable.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@hurricane.ocf.berkeley.edu>,
···@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ...
> [*] The MOP is really, really, really useful when you need it, but
> it's not in the ANSI standard. If CLISP actually implemented CLOS as
> specified by ANSI, and had no MOP, I wouldn't be hating. But if you
> like OOP, the claim that CLISP is ANSI, or "almost ANSI" is laughable.
i haven't tried it, but i vaguely remember having read somewhere in
the clisp documentation that a MOP capable CLOS package is available
hs
--
don't use malice as an explanation when stupidity suffices