Lisp for Linux
An Engineer
I know nothing about Lisp at all but find that I now need to get some
Lisp code running in a Linux environment. I don't currently have a lisp
interpreter/compiler but have looked at the web to find one. Although
this looks promising when I look at the web pages I can make very little
sense of them.
What I really need is an IDIOT's guide to what I need to download to get
a Lisp program to run in a Red Hat Linux environment. Can anyone help?
Thanks
Andrew
An Engineer
Friedrich Dominicus
You got more than one option. I'm sure RedHat has prepackaged Lisp
Interpreters/compilers. You can get an *rpm package form LispWorks
too. I would suggest using LispWorks because you do have to setup the
least from all the options.
Regards
Friedrich
quasi
>My situation is thus:
>What I really need is an IDIOT's guide to what I need to download to get
>a Lisp program to run in a Red Hat Linux environment. Can anyone help?
>
If you ever consider the Debian GNU/Linux distribution, CMUCL, Clisp,
GCL work almost out of the box. Just download the .deb files or
apt-get can download/install/configure them for you.
Of these CMUCL is a native compiler
Clisp is a byte-code compiler
GCL compiler via C
hth
quasi
--
(be-good-p)
NIL
Matthew Danish
Except that GCL isn't an ANSI Common Lisp compiler last time I checked,
so you probably shouldn't recommend it (at least, not without qualifying
that recommendation).
http://ww.telent.net/cliki/index is a good starting place.
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Thomas F. Burdick
> On Fri, Sep 20, 2002 at 05:52:23PM +0530, quasi wrote:
> > On Fri, 20 Sep 2002 09:44:13 +0100, An Engineer <no...@here.com> wrote:
> >
> > >My situation is thus:
> > >What I really need is an IDIOT's guide to what I need to download to get
> > >a Lisp program to run in a Red Hat Linux environment. Can anyone help?
> > >
> >
> > If you ever consider the Debian GNU/Linux distribution, CMUCL, Clisp,
> > GCL work almost out of the box. Just download the .deb files or
> > apt-get can download/install/configure them for you.
> >
> > Of these CMUCL is a native compiler
> > Clisp is a byte-code compiler
> > GCL compiler via C
>
> Except that GCL isn't an ANSI Common Lisp compiler last time I checked,
> so you probably shouldn't recommend it (at least, not without qualifying
> that recommendation).
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.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Matthew Danish
> 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.
As I just discovered today:
[1]> (defgeneric foo (t t))
*** - DEFGENERIC FOO: duplicate variable name T
1. Break [2]>
I went and looked at section 3.4.2 but couldn't find anything to justify
this error.
bruce
In article <xcv65x0...@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
Thomas F. Burdick
> In article <xcv65x0...@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.
Hartmann Schaffer
Matthew Danish <mda...@andrew.cmu.edu> writes:
> On Fri, Sep 20, 2002 at 12:11:24PM -0700, 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.
>
> As I just discovered today:
>
> [1]> (defgeneric foo (t t))
>
> *** - DEFGENERIC FOO: duplicate variable name T
> 1. Break [2]>
>
> I went and looked at section 3.4.2 but couldn't find anything to justify
> this error.
well, you tried to define a generic function with two identically
named arguments. otoh,
(defmethod foo ((t t)) t)
doesn't complain (i didn't try it any further than that)
hs
--
don't use malice as an explanation when stupidity suffices
Vassil Nikolov
> On Fri, Sep 20, 2002 at 12:11:24PM -0700, 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.
>
> As I just discovered today:
>
> [1]> (defgeneric foo (t t))
>
> *** - DEFGENERIC FOO: duplicate variable name T
> 1. Break [2]>
>
> I went and looked at section 3.4.2 but couldn't find anything to justify
> this error.
That a generic function lambda list may have duplicate symbols
in it is _not_ listed among the differences from an ordinary
lambda list.
Also, it is not allowed to have a constant such as T there.
---Vassil.
Hartmann Schaffer
t...@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
Vassil Nikolov
It should have---binding a constant is not allowed.
Now, if you have a class named X, and X is not a constant,
you could say
(defmethod foo ((x x)) x)
---Vassil.
Michael A. Koerber
> a Lisp program to run in a Red Hat Linux environment. Can anyone help?
1. I'm responding based on your e-mail "An Engineer", which to me means
you'll be interested in numerically intensive applications. If this
is true get CMUCL (http://www.cons.org/cmucl/) or purchase ACL (http://www.franz.com/)
The links above should be sufficient. See http://www.lisp.org/ for
additional links.
mike
--
**************************************************
Dr Michael A. Koerber Micro$oft Free Zone
MIT/Lincoln Laboratory
Michael Hudson
> On Fri, Sep 20, 2002 at 12:11:24PM -0700, 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.
>
> As I just discovered today:
>
> [1]> (defgeneric foo (t t))
>
> *** - DEFGENERIC FOO: duplicate variable name T
> 1. Break [2]>
T is a BAD variable name, quite apart from anything else...
Cheers,
M.
--
incidentally, asking why things are "left out of the language" is
a good sign that the asker is fairly clueless.
-- Erik Naggum, comp.lang.lisp
Matthew Danish
> > [1]> (defgeneric foo (t t))
> >
> > *** - DEFGENERIC FOO: duplicate variable name T
> > 1. Break [2]>
>
> T is a BAD variable name, quite apart from anything else...
As I've recently discovered, generic functions take variable names as
arguments, whereas I had previously thought that only the structure
mattered. I'm going to have to poke around a bit and figure out where I
picked up the [bad] habit of using T in generic function lambda lists
(usually only for quickly hacked up code, fortunately).