Hi,
I've scanned the web and Google on-and-off for a while for this, but I've had
little luck. I'm still looking, but I'm going to give into my pride and just
ask. How can I pass command line arguments to a Common Lisp script? I know
that Comon Lisp (the "clisp" file/program) has arguments, but I'm wondering how
I can pass my own arguments to a program. I ask because I'm convinced that
command line arguments are the way to pass data to a CGI-script -- it worked
that way with my little C++ parser. Any suggestions on how or a link o how?
Thanks.
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
···········@aol.commune (Andrew Burton) writes:
> Hi,
>
> I've scanned the web and Google on-and-off for a while for this, but
> I've had little luck. I'm still looking, but I'm going to give into
> my pride and just ask. How can I pass command line arguments to a
> Common Lisp script? I know that Comon Lisp (the "clisp"
> file/program) has arguments, but I'm wondering how I can pass my own
> arguments to a program. I ask because I'm convinced that command
> line arguments are the way to pass data to a CGI-script -- it worked
> that way with my little C++ parser. Any suggestions on how or a link
> o how? Thanks.
They're in ext:*args*. See:
<http://clisp.cons.org/impnotes.html#quickstart>
However, I don't think CGI works the way you think it does--unless
they've changed it quite a bit since I was doing CGI programming (or
unless you mean Computer Generated Imagery). Web CGI's get their input
from a bunch of environment variables and standard input.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
>However, I don't think CGI works the way
> you think it does--unless they've
> changed it quite a bit since I was doing
> CGI programming (or unless you mean
> Computer Generated Imagery).
Well, that was how mine worked (and it did work), however I'd lay money on you
being right. My little parser worked (barely) on a very limited scale and in a
very ineffecient way. I probably need to dig into it more. Thanks for the
link. :)
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
···········@aol.commune (Andrew Burton) writes:
> How can I pass command line arguments to a Common Lisp script? I
> know that Comon Lisp (the "clisp" file/program) has arguments, but
> I'm wondering how I can pass my own arguments to a program.
Now that Peter has given you the answer you need (hopefully), allow
one more note:
Clisp is just one implementation of the Common Lisp language, like gcc
is just one implementation of C. There are lots of others. Handling
command line arguments (or environment variables) is not specified by
the CL standard, so even if probably all implementations support it in
one way or another, the way they actually do will differ. You can use
them, but you should keep in mind that you code will likely not be
portable to other Lisps.
You might want to use something like the PORT library, that gives you
uniform access to some implementation-dependent features. It is
available from CLOCC, http://clocc.sourceforge.net.
Regards
Henrik
Henrik Motakef wrote:
> Handling
> command line arguments (or environment variables) is not specified by
> the CL standard, so even if probably all implementations support it in
> one way or another, the way they actually do will differ.
I somehow doubt that the implementations by Symbolics, LMI, or TI
supported command line arguments. Many well-regarded programmers
consider it a design flaw in Windows, *nix, and MacOS that there is
anywhere to put command-line arguments.
"Steven M. Haflich" <·················@alum.mit.edu> wrote in message news:<················@alum.mit.edu>...
> I somehow doubt that the implementations by Symbolics, LMI, or TI
> supported command line arguments. Many well-regarded programmers
> consider it a design flaw in Windows, *nix, and MacOS that there is
> anywhere to put command-line arguments.
Fascinating. Could you elaborate on this? Why do they think that? And who?
Cheers, Gabor
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Henrik Motakef wrote:
> > Handling
> > command line arguments (or environment variables) is not specified by
> > the CL standard, so even if probably all implementations support it in
> > one way or another, the way they actually do will differ.
>
> I somehow doubt that the implementations by Symbolics, LMI, or TI
> supported command line arguments. Many well-regarded programmers
> consider it a design flaw in Windows, *nix, and MacOS that there is
> anywhere to put command-line arguments.
Symbolics' entry to Lisp, of course, was when you started the operating
system. You ran a boot script that loaded the world and set the paging
files and stuff, and finally did a 'Start' which required no args.
So yes, in that sense, entry to Lisp didn't take args that you would want
to be seeing or modifying. No end-users supplied additional args to
starting their machine that were likely to have application usefulness.
However, Symbolics did have, per 'application framework', commands that
were like CLIM's commands, and you could get a command loop that prompted
for 'relevant commands'. The mechanism for supplying args was, on the
receiving end, really a lot like &optional and &rest args, but with
additional adornment to understand types, defaults, guide prompts, etc.
From the user standpont, you were already _in_ Lisp and all you were
doing was something like
Command> Login JDoe :Init File (filename or None) None
I personally don't consider it a design flaw to have command line arguments.
I think it's useful when writing scripts.
One might make the claim that drag-and-drop of a document onto an application
was like doing a command saying "application documentname", but the problem
with that analogy is that it's hard to embed that into anything other than
a visual programming language. In the end, it's handy to review your
'program' textually, and that's where scripting languages are useful.
(By scripting language I mean any of Lisp, Java, JavaScript, HyperTalk,
sh/csh/bash, Perl, etc. Something written with syntax reducible to
plain text.)
> Clisp is just one implementation of the
> Common Lisp language, like gcc is just
> one implementation of C.
I think it came from http://clisp.cons.org -- I think. While I have your ear,
where can I find a page that gives the full (and seemingly sordid) family tree
of Lisp? I know there was Lisp once, bourne of a mathematician cum Fortran
hacker. From there I know it evolved into dialects like Sceme, CLisp, and
Dylan (to name a very, very few). But where can I go to find out how many
children there are of Lisp and CLisp. THANKS! :)
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
On Sun, Mar 30, 2003 at 09:44:13PM +0000, Andrew Burton wrote:
> I think it came from http://clisp.cons.org -- I think. While I have your ear,
> where can I find a page that gives the full (and seemingly sordid) family tree
> of Lisp? I know there was Lisp once, bourne of a mathematician cum Fortran
> hacker. From there I know it evolved into dialects like Sceme, CLisp, and
> Dylan (to name a very, very few). But where can I go to find out how many
> children there are of Lisp and CLisp. THANKS! :)
http://www.lisp.org/table/history.htm
Please do not refer to the language Common Lisp as ``CLisp.'' You will
only get yourself, and others confused. Henrik has already pointed out
that Common Lisp is a /language/ and CLISP is an /implementation/ of
said language. These terms are distinct. CLISP is a software program
that implements the Common Lisp /language/ (to a certain extent), but it
is NOT the only software which does so. If you want a shorter name for
Common Lisp, use CL.
--
; Matthew Danish <·······@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."
The _ONLY_ reason I mentioned "clisp" the first time was to give people an
indication of what interpreter I was using. If you'll check my first post,
you'll see I referred to it as "Common Lisp" except when I gave the name of my
interpreter.
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
Sorry if my previous post sounded snotty. I'm just tired of myself not
understanding the lingo. I reread what you said and followed the link. Let me
see if I finally got this right: Comon Lisp is the language, like C or Pascal.
CLisp is the compiler, like gcc or Delphi (an IDE, I know). When discussing
Common Lisp, type "Common Lisp" or "CL" in sentences. When discussing the
program, type "CLisp" or "clisp" in the sentence?
Is that it?
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
On Sun, Mar 30, 2003 at 11:20:34PM +0000, Andrew Burton wrote:
> Comon Lisp is the language, like C or Pascal. CLisp is the compiler,
> like gcc or Delphi (an IDE, I know). When discussing Common Lisp,
> type "Common Lisp" or "CL" in sentences. When discussing the program,
> type "CLisp" or "clisp" in the sentence?
> Is that it?
Yes. To add a less important, somewhat picky note: I've never seen
CLISP referred to as CLisp, it's always ``CLISP'' or ``clisp.'' But
it's more important not to confuse CLISP with Common Lisp.
--
; Matthew Danish <·······@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."
Andrew Burton wrote:
> Sorry if my previous post sounded snotty. I'm just tired of myself not
> understanding the lingo. I reread what you said and followed the link. Let me
> see if I finally got this right: Comon Lisp is the language, like C or Pascal.
> CLisp is the compiler, like gcc or Delphi (an IDE, I know). When discussing
> Common Lisp, type "Common Lisp" or "CL" in sentences. When discussing the
> program, type "CLisp" or "clisp" in the sentence?
Almost, but you are still afflicted by the unfortunate historical
terminology confusions surrounding Lisp.
In almost any context, and for almost every implementation, it distorts
things to call a CL implementation a "compiler." Every implementation
must have a compiler (at least one that satisfies "minimal compilation")
but the compiler is only a part of the implementation. There must also
be a library of runtime support and required functions that comprise,
along with user application code, a lisp world. In fact, the compiler
is typically much less than half of the Lisp implementation, even a small
implementation of the ANS lacking GUI's and other higher-level libraries.
So, rather than refer to a "Common Lisp compiler" you should refer
to a "Common Lisp implementation."
In C, it _almost_ makes sense to speak of compiling code outside the
context of libc.so and all the other standard libraries. The original
K&R C was defined this way, with no required library definitions at all.
But the langauge was _rarely_ used that way -- I did so only once, when
writing some special real-time PDP11 programs that ran outside any
operating system.
CL application code, compiled or not, makes no sense without the
required library of cl-package functions, most of which will _not_
be inlined by the compiler.
[I believe that terminology confusion like this is instigated and
promulgated by evil, ignorant, self-serving marketing people
surrounding the Lisp business. I know for a fact that the confusion
of "CLOS" being the same thing as "Lisp" was promulgated by marketing
people, but I want clearly to state that the guilty parties are _not_
people still employed by and involved in the industry. [I suppose
this is a flame that will not soon die down, but I shall try not to
follow the spreading blaze myself.]]
I'm _not_ sorry that my current post sounds snotty... It is
intentional. :-)
"Steven M. Haflich" <·················@alum.mit.edu> wrote in message news:<·····················@newssvr21.news.prodigy.com>...
> Andrew Burton wrote:
> > Sorry if my previous post sounded snotty. I'm just tired of myself not
> > understanding the lingo. I reread what you said and followed the link. Let me
> > see if I finally got this right: Comon Lisp is the language, like C or Pascal.
> > CLisp is the compiler, like gcc or Delphi (an IDE, I know). When discussing
> > Common Lisp, type "Common Lisp" or "CL" in sentences. When discussing the
> > program, type "CLisp" or "clisp" in the sentence?
>
> Almost, but you are still afflicted by the unfortunate historical
> terminology confusions surrounding Lisp.
Someone *really* afflicted by historic confusions would say ``Lisp
interpreter''. If people say ``compiler'' instead of
``implementation'', leave them alone! :)
>Every implementation
>must have a compiler (at least one that satisfies "minimal compilation")
>but the compiler is only a part of the implementation.
Right, just like gcc and Delphi. I don't want to be a troll and stir this up
after four days, but I want to make this known: I know what a compiler is. I
know that Common Lisp, clisp, scsh, Scheme, etc. need libraries and what not.
They need them the same way gcc needs libraries, the way Delphi needs
libraries. My point, the single reason I said "CLisp is the compiler" is
because the file "clisp" buried in my various bin and sbin directories is the
program that takes my source code and all the parenthesis I type and
converts/compiles/interprets it to something the Pentium can understand -- and
I say "Pentium" since that's a specific implementation of the CPU piece of
hardware. clisp, gcc, and Delphi compile, which in and of itself is kind of
slang term because it overlooks translation, linking, and such that goes into
this magical process. So, yes, clisp is like gcc or Delphi, it's the compiler.
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
···········@aol.commune (Andrew Burton) writes:
>>Every implementation
>>must have a compiler (at least one that satisfies "minimal compilation")
>>but the compiler is only a part of the implementation.
>
> Right, just like gcc and Delphi. I don't want to be a troll and stir this up
> after four days, but I want to make this known: I know what a compiler is. I
> know that Common Lisp, clisp, scsh, Scheme, etc. need libraries and what not.
> They need them the same way gcc needs libraries, the way Delphi needs
> libraries.
But with gcc you also need external programs to debug, profile, trace,
look up documentation, browse code cross-references, manage
compilation dependencies etc, which is all integrated (or integratable
with some libraries) in a Lisp environment like CLISP.
I guess Delphi does a lot of this, though probably not as integrated
as a Lisp. So, I'd say, the clisp program is closer to an IDE than to
a mere compiler :)
Then again, words might not matter that much.
Regards
Henrik
>Then again, words might not matter that much.
I like words, they're my preferred method of communications. :)
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
* Andrew Burton wrote:
> So, yes, clisp is like gcc or Delphi, it's the compiler.
No, it really isn't like them. But never mind, if you haven't
understood this far, you probably never will.
--tim
>But never mind, if you haven't understood this far, you probably never will.
This is what scares me, though. I don't see the difference. I've read the
history of Lisp. I've read the history of C. I've used clisp and scsh --
naming the "implementations," I believe. I've used gcc. I don't see the
difference, and I swear I want to!
I mean, here... if I type in:
clisp -l -o filename -f filename.lisp (apologies if I have mangled arguments)
...it compiles it my program into a language the machine understands, the same
as if I type:
gcc -o filename filename.c
...right? Henrik said it was more of an IDE, which I can dig. Is that the
main thing I'm not getting, that clisp is more of an IDE than just compiler?
If that's what I'm missing, then I apologize. I've not gotten to all the
features, so as far as I know, for me, it's a compiler/interpreter. I will
take it on good faith, until I use these features, that it's more than a
compiler from now on. (I did finally grasp the Common Lisp/clisp
dialect/implementation thing, so maybe I'll get this.)
I don't want to cause trouble, I want to learn what I can, but picking up Lisp
is 90-degrees from most anything else I've ever programmed with. My apologies
in advance for when I butt heads with people.
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
In article <·····························@mb-fk.aol.com>,
···········@aol.commune (Andrew Burton) wrote:
> I've used clisp and scsh --
> naming the "implementations," I believe. I've used gcc. I don't see the
> difference, and I swear I want to!
That is hard to believe. The difference in behavior between CLisp and gcc
when invoked without arguments is quite striking and immediately obvious.
> I mean, here... if I type in:
>
> clisp -l -o filename -f filename.lisp (apologies if I have mangled arguments)
>
> ...it compiles it my program into a language the machine understands, the same
> as if I type:
>
> gcc -o filename filename.c
>
> ...right?
Yes, but so what? If I type "gcc -v" then the output looks a lot like if
I type, say, "perl -v" or "gdb -v". That does not mean that gcc, perl and
gdb all do the same thing.
> Henrik said it was more of an IDE, which I can dig. Is that the
> main thing I'm not getting, that clisp is more of an IDE than just compiler?
Almost. *LISP* (the language itself, as opposed to any particular
implementation of Lisp, including CLisp) is more than just a compiler. As
a consequence, *all* implementations of Lisp, including but not limited to
CLisp, are more than just a compiler.
E.
--
The opinions expressed here are my own and do not necessarily
reflect the views of JPL or NASA.
···········@aol.commune (Andrew Burton) writes:
> >But never mind, if you haven't understood this far, you probably never will.
>
> This is what scares me, though. I don't see the difference. I've
> read the history of Lisp. I've read the history of C. I've used
> clisp and scsh -- naming the "implementations," I believe. I've used
> gcc. I don't see the difference, and I swear I want to!
>
> I mean, here... if I type in:
>
> clisp -l -o filename -f filename.lisp (apologies if I have mangled arguments)
>
> ...it compiles it my program into a language the machine understands, the same
> as if I type:
>
> gcc -o filename filename.c
>
> ...right? Henrik said it was more of an IDE, which I can dig. Is
> that the main thing I'm not getting, that clisp is more of an IDE
> than just compiler? If that's what I'm missing, then I apologize.
> I've not gotten to all the features, so as far as I know, for me,
> it's a compiler/interpreter. I will take it on good faith, until I
> use these features, that it's more than a compiler from now on. (I
> did finally grasp the Common Lisp/clisp dialect/implementation
> thing, so maybe I'll get this.)
>
> I don't want to cause trouble, I want to learn what I can, but
> picking up Lisp is 90-degrees from most anything else I've ever
> programmed with. My apologies in advance for when I butt heads with
> people.
Well, the distinction that you might want to make is that you're usage
above is not a very typical use of a Lisp "compiler". A seasoned Lisp
hacker is much more likely to do:
[·····@localhost src]$ clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2002
[1]> (compile-file "filename.lisp")
Compiling file /home/peter/javamonkey/lisp/src/filename.lisp ...
Wrote file /home/peter/javamonkey/lisp/src/filename.fas
0 errors, 0 warnings
#P"/home/peter/javamonkey/lisp/src/filename.fas" ;
NIL ;
NIL
[2]> (load "filename")
;; Loading file /home/peter/javamonkey/lisp/src/filename.fas ...
;; Loaded file /home/peter/javamonkey/lisp/src/filename.fas
T
[3]>
And then hack on filename.lisp some. And redefine some of the
functions in filename.lisp. And load some other files. And generally
keep CLISP running for days on end, debugging, profiling, and tracing
methods, and adding new functionality, from other files, etc.
So when you say 'clisp -c -l filename.lisp -o filename' you're just
using one part of what CLISP is.
Also, it's not true that the result of 'clisp -c -l ...' "compiles
[your] program into a language the machine understands". CLISP
compiles into a form that its own bytecode interpreter understands. On
Unix you can smoosh a #!/usr/local/bin/clisp on the front of the
resulting .fas file and it will be runnable like a Perl or Python
script. Of course you can do the same thing with a .lisp file.
Other Common Lisp implementations have other ways of packaging
applications, including some that *do* compile your Lisp code into
machine code. But in those two, you still work with the system much
differently than a C programmer works with gcc.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
And this is where I got lost. I do run clisp when I'm working with my clisp
programs, but only as a means to see if a function will work. I'll run clisp,
type in (defun x (y) (x (+ y 1))), then go back out to vi and continue working.
And, notice I use vi, not Emacs. This whole concept of Lisp being a listening
language blos my mind. It's why I didn't want to respond to Edi, because my
mind was blown by the (dare I throw the buzz word) paradigm shift. I'm used to
shells, and when I read about scsh I thought "This is cute, a Lisp shell," but
I swear using Lisp like Edi explained blew my mind. It also explains, I think,
where I went wrong calling Lisp a "compiler," so again I apologize and plead
ignorance.
Also, yes, there should be a book. I suggest the first paragraph goes
something like this: "Hey, you know everything you've learned up to now, forget
it. Throw out 'gcc -o', trash bin the command line, and send your text editor
downtown with a fifty to get stuffed. Lisp is all you need to know here
because it's all you need to use here."
I wish those documents I'd read before had said it that crass or plainly.
Thank you.
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
···········@aol.commune (Andrew Burton) writes:
> And this is where I got lost. I do run clisp when I'm working with my clisp
> programs, but only as a means to see if a function will work. I'll run clisp,
> type in (defun x (y) (x (+ y 1))), then go back out to vi and continue working.
> And, notice I use vi, not Emacs. This whole concept of Lisp being a listening
> language blos my mind. It's why I didn't want to respond to Edi, because my
> mind was blown by the (dare I throw the buzz word) paradigm shift. I'm used to
> shells, and when I read about scsh I thought "This is cute, a Lisp shell," but
> I swear using Lisp like Edi explained blew my mind. It also explains, I think,
> where I went wrong calling Lisp a "compiler," so again I apologize and plead
> ignorance.
>
> Also, yes, there should be a book. I suggest the first paragraph goes
> something like this: "Hey, you know everything you've learned up to now, forget
> it. Throw out 'gcc -o', trash bin the command line, and send your text editor
> downtown with a fifty to get stuffed. Lisp is all you need to know here
> because it's all you need to use here."
>
> I wish those documents I'd read before had said it that crass or plainly.
> Thank you.
I suspect that a major reason it took you so long to get how a Lisp
environment is different from a Unix/C one, is that you gravitated
towards a setup that let you get away with doing things the Unix/C
way. If you'd tried MCL, or Lispworks, or CMUCL/Hemlock, you'd have
landed yourself in an environment where you couldn't just keep doing
things the same old way. From this post, I suspect that even now,
you're still working at file-level granularity: load a .lisp file,
check some things at the toplevel, edit the .lisp file, repeat. You
should be working at a toplevel-sexp (ie, defun, defclass, etc) level
of granularity: load a .lisp file, check things at the toplevel, edit
a definition and evaluate the new definition, check things at the
toplevel, edit a definition ...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Actually, right now I'm trying to:
a. Install emacs on my Windows machine.
b. Find an emacs tutorial.
c. find an elisp tutorial.
Other than that, I haven't done much except piddle in clisp, trying to get
myself in the proper mindset.
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
···········@aol.commune (Andrew Burton) writes:
> Actually, right now I'm trying to:
>
> a. Install emacs on my Windows machine.
<http://www.gnu.org/software/emacs/windows/ntemacs.html>
I happen to prefer XEmacs on Windows (but GNU Emacs on Unix; and no, I
cannot explain why) - the installer works well, and the integrated
package management tends to be quite useful on such a spartan OS.
> b. Find an emacs tutorial.
C-h t (i.e. Control-h, then t) in Emacs covers the basics. C-h i gets
you in the info tree, 'm emacs RET' (or 'm xemacs RET') to the Emacs
manual. This is only so useful - Emacs is huge, and hence hard to
grasp at the beginning.
There are some Emacs-specific newsgroups where you can ask for help,
but the hardest thing is to get used to the Emacs way - you can only
do that by practicing.
You might find some inspiring things in the emacs Wiki at
<http://www.emacswiki.org>.
> c. find an elisp tutorial.
<http://www.delorie.com/gnu/docs/emacs-lisp-intro/emacs-lisp-intro_toc.html>
<http://www.gnu.org/manual/elisp-manual-20-2.5/elisp.html>
Regards
Henrik
···········@aol.commune (Andrew Burton) writes:
> Actually, right now I'm trying to:
>
> a. Install emacs on my Windows machine.
For this step (including ILISP setup) try Bill Clementson's very
helpful tutorial at
<http://cl-cookbook.sourceforge.net/windows.html>
> b. Find an emacs tutorial.
Emacs itself has one. Try <Ctrl>-h t.
> c. find an elisp tutorial.
<http://www.delorie.com/gnu/docs/emacs-lisp-intro/emacs-lisp-intro_toc.html>
There are newer versions available and you can also load them into
Emacs and read them from there. Also, some good books about this topic
are available including
<http://www.oreilly.com/catalog/gnuext/>.
But note that you only need to know these details if you want to
extend Emacs itself. Knowledge of Emacs Lisp is _not_ needed to
understand Common Lisp. (It might in fact be counterproductive because
Emacs Lisp is in some ways quite different from Common Lisp.)
Edi.
Andrew Burton wrote:
>
> And this is where I got lost. I do run clisp when I'm working ...
> Also, yes, there should be a book. I suggest the first paragraph
> goes something like this: "Hey, you know everything you've learned
> up to now, forget it. Throw out 'gcc -o', trash bin the command
> line, and send your text editor downtown with a fifty to get
> stuffed. Lisp is all you need to know here because it's all you
> need to use here."
>
> I wish those documents I'd read before had said it that crass or
> plainly. Thank you.
It may help to think of it as an environment? Something between an
IDE, up to and including an OS. Familiarity with Image (save-lisp)
based systems (ST, Self) helps with the workflow.
* Andrew Burton wrote:
> clisp -l -o filename -f filename.lisp (apologies if I have mangled arguments)
> ...it compiles it my program into a language the machine understands, the same
> as if I type:
> gcc -o filename filename.c
But that's comparing a completely weird use of a Lisp environment with
a completely standard usage of a C compiler.
A better way of thinking of a Lisp environment is that it's like a
Unix shell, except that it's a shell which is oriented towards program
development rather than file manipulation and program invocation. So
the typical way of using a lisp environment is that you start it and
then you live in it `for ever' - often for days, instead of using it
to batch process files like as a C compiler typically does. Of
course, you *can* use it like a C compiler is used, but that is not
what it's about.
--tim
···········@aol.commune (Andrew Burton) writes:
> I mean, here... if I type in:
>
> clisp -l -o filename -f filename.lisp (apologies if I have mangled arguments)
>
> ...it compiles it my program into a language the machine understands, the same
> as if I type:
>
> gcc -o filename filename.c
>
> ...right?
No, actually. The usual way to use a CL implementation is _not_ to use
it like this (i.e. as a command line tool or as a Unix 'filter' if
you'd like to see it like this) but to start it like
clisp
and then work _inside_ of it[1] - load files, change functions and
classes on the fly, use the debugger, inspect objects, query the
system for documentation strings, all that stuff. If you haven't done
that you haven't really used Lisp.
Edi.
[1] Well, the _real_ way to do it (at least what most people do,
anyway) is not to start CLISP (or CMUCL, or SBCL, or OpenMCL, or
another CL implementation) directly but from within Emacs using
ILISP <http://sourceforge.net/projects/ilisp/> to control it.
Or, if you use a commercial CL implementation like LispWorks,
AllegroCL, or MCL, you'll probably use their IDE instead of Emacs
but it boils down to the same thing: You usually don't ask a
compiler to compile a static source file but instead you interact
with a 'listener' which provides a 'read-eval-print loop' (REPL)
to help you to interactively develop, test, and debug your
applications.
You shouldn't compare Lisp to other languages until you've grasped
these basic concepts. A book might help...
Edi Weitz <···@agharta.de> writes:
> You shouldn't compare Lisp to other languages until you've grasped
> these basic concepts. A book might help...
Yes, a book would help, yet the Lisp books I've seen don't explain
such a working model. They start out mentioning that the REPL provides
interactive evaluation of, say, addition, and then move on into the
language. The environment is left, as they say, as an exercise for the
reader. (No pun intended.)
Consider the vast swarm of "Visual C++" books published in the last
few years. These books are usually terrible as C++ language
introductions and references; really, they're not even about C++. But
they succeed with a different goal: showing the novice reader a
possible working model. They illustrate one way to build software in a
particular language using a particular tool.
Such a book could be written about Emacs/ilisp, or any other Lisp IDE,
that would go beyond -- or even around -- language and into the
mundane realm of attendant tools.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Steven E. Harris <········@raytheon.com> writes:
> Edi Weitz <···@agharta.de> writes:
>
> > You shouldn't compare Lisp to other languages until you've grasped
> > these basic concepts. A book might help...
>
> Yes, a book would help, yet the Lisp books I've seen don't explain
> such a working model. They start out mentioning that the REPL provides
> interactive evaluation of, say, addition, and then move on into the
> language. The environment is left, as they say, as an exercise for the
> reader. (No pun intended.)
Well, for general-purpose books, this is true. But most
implementations come with documentation. "Getting Started With
Macintosh Common Lisp" is a great example of what this should look
like. I think CMUCL is the only free-software lisp that has something
similar (the CMUCL and Hemlock users' manuals).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Steven E. Harris <········@raytheon.com> writes:
> Edi Weitz <···@agharta.de> writes:
>
> > You shouldn't compare Lisp to other languages until you've grasped
> > these basic concepts. A book might help...
>
> Yes, a book would help, yet the Lisp books I've seen don't explain
> such a working model. They start out mentioning that the REPL provides
> interactive evaluation of, say, addition, and then move on into the
> language. The environment is left, as they say, as an exercise for the
> reader. (No pun intended.)
>
> Consider the vast swarm of "Visual C++" books published in the last
> few years. These books are usually terrible as C++ language
> introductions and references; really, they're not even about C++. But
> they succeed with a different goal: showing the novice reader a
> possible working model. They illustrate one way to build software in a
> particular language using a particular tool.
>
> Such a book could be written about Emacs/ilisp, or any other Lisp IDE,
> that would go beyond -- or even around -- language and into the
> mundane realm of attendant tools.
Agreed - such a book is definitely not there and it certainly would
help a lot of people.
One of the problems, of course, is that Common Lisp is a language
defined by a standard, not by one implementation, so it's a lot easier
to write book #237 about Perl than to write book #1 about how to use
'the' CL IDE (which one?). Plus, there isn't one dominating vendor,
neither commercial nor 'free', with a market share comparable to
Microsoft's Visual Studio, so if you were going to write such a book
and would also want to earn money with it what would be your subject?
AllegroCL with the Windows IDE? AllegroCL with Emacs/ELI? LispWorks?
MCL? Emacs/ILISP for all supported platforms? Or only Emacs/ILISP with
one CL implementation that's particularly well supported like, say,
CMUCL? Or rather XEmacs? Jabberwocky? Sometimes it might hurt to have
choice... :)
That said, there are indications that such a book might actually
happen. Not today, not tomorrow, but watch out for it...
Cheers,
Edi.
Edi Weitz <···@agharta.de> writes:
> Plus, there isn't one dominating vendor, neither commercial nor
> 'free', with a market share comparable to Microsoft's Visual Studio,
> so if you were going to write such a book and would also want to
> earn money with it what would be your subject?
Good point. And amongst all of these tools and CL implementation
combinations, does there exist a consistent working model?
With C++, the language itself can't possibly hint at such a model; the
assumption is that everyone either builds up a model from tools
(editor, make, compiler suite) or buys into a complete wrapped-up
model like MS Visual Studio, and the language itself has nothing to
say about the setup.
With Lisp, less distinction is made between the language and the
supporting environment. Consider the CL function "inspect." The
interface possibilities are endless, yet the existence and intention
of the function is specified. It's a kind of prescription for a
working environment. Coming from the C++ world, that's a strange thing
to find in a language specification. It sets up more expectations for
how a Lisp suite offers not just the static language, but the
interactive experience implied by that language.
So far I have only used XEmacs/ilisp/clisp. It's nice and efficient,
but I can definitely imagine a better inspector and debugger. When I
hear people say, "One keeps the Lisp image running, and debugs the
program along the way," I wonder about what this debugger could be
like. Surely it must be better than wrapping a form with "step" in
clisp.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Steven E. Harris <········@raytheon.com> writes:
> Edi Weitz <···@agharta.de> writes:
>
>> Plus, there isn't one dominating vendor, neither commercial nor
>> 'free', with a market share comparable to Microsoft's Visual Studio,
>> so if you were going to write such a book and would also want to
>> earn money with it what would be your subject?
>
> Good point. And amongst all of these tools and CL implementation
> combinations, does there exist a consistent working model?
you bet. although after two months of pretty active use of Lisp, I'm
not sure I grok this model completely. a book explaining the
philosophy of Lisp development would be great. (I'd love to have a
mentor, actually, but even to have a distant theoretical possibility
of such luxury one has to live in Cambridge, Mass or maybe Oslo. oh
well.)
> With Lisp, less distinction is made between the language and the
> supporting environment. Consider the CL function "inspect."
wimp. consider "break". or "invoke-debugger".
great stuff.
> So far I have only used XEmacs/ilisp/clisp. It's nice and efficient,
> but I can definitely imagine a better inspector and debugger.
clisp's debugger is kinda clunky, and doesn't work for compiled
code. and the conditional tracing doesn't work.
clisp's /only/ redeeming feature is portability, IM not very long E.
I tend to use CmuCL for actual developement & debugging and like it
better.
> When I hear people say, "One keeps the Lisp image running, and
> debugs the program along the way," I wonder about what this debugger
> could be like. Surely it must be better than wrapping a form with
> "step" in clisp.
I'd love something like Emacs's edebug. I'm sure the commercial
offerings have good debuggers.
but debuggers & stuff can be adequately explained in
implementation-specific documentation. what I'd really like in a book
is a discussion of more implementation-neutral but nevertheless
important development-cycle-related stuff, like:
* why does Lisp bother having `defconstant' if my implementation
raises conditions when I reload a file that contains them.
* what is a good way to organize code in files.
* what happens to :before and :after methods when you reload the file
where they are defined; specifically, do they accumulate or do they
get replaced? if they accumulate, what would be a good way to use
them?
* how to use a defsystem utility.
* why is it wrong to use too many packages.
* etc, etc.
--
a newbie: Why doesn't Lisp have pass by reference?
Erik Naggum: Because C++ doesn't have multiple return values.
(from a conversation in comp.lang.lisp)
Michael Livshin <······@cmm.kakpryg.net> writes:
> implementation-specific documentation. what I'd really like in a book
> is a discussion of more implementation-neutral but nevertheless
> important development-cycle-related stuff, like:
> * what happens to :before and :after methods when you reload the file
> where they are defined; specifically, do they accumulate or do they
> get replaced? if they accumulate, what would be a good way to use
> them?
Overwritten.
(demethod foo :after/before/:around/nothing
(arg1-with-or-without-class/type arg2-w/w/o/c arg3-...)
...body)
specifies a unique method, indexed/keyed by the specializers and
classes.
If you repeat it with exactly the same dispatching classes and
:after/:before specifiers you'll overwrite the previous definition.
Variable names don't matter. Classnames do:
(defmethod foo :after ((myvar CONS)) ...somebody)
will be overwritten by a subsequent
(defmethod foo :after ((thyvar CONS)) ...anotherbody)
Note how CONS and other built-in classes may be used to specialize,
not only CLOS classes obtained from DEFCLASS.
E.g. DESCRIBE-OBJECT can use this.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Edi Weitz wrote:
>
> Steven E. Harris <········@raytheon.com> writes:
> > Consider the vast swarm of "Visual C++" books published in the last
> > few years. These books are usually terrible as C++ language
> > introductions and references; really, they're not even about C++. But
> > they succeed with a different goal: showing the novice reader a
> > possible working model. They illustrate one way to build software in a
> > particular language using a particular tool.
> >
> > Such a book could be written about Emacs/ilisp, or any other Lisp IDE,
> > that would go beyond -- or even around -- language and into the
> > mundane realm of attendant tools.
>
> Agreed - such a book is definitely not there and it certainly would
> help a lot of people.
Strictly speaking, at least one book trying to achieve something like
that exists:
Hank Bromley, Richard Lamson
Lisp Lore: A Guide to Programming the Lisp Machine
The problem with that is that it isn't of much use without a Symbolics
LispM.
--
Martti Halminen <···············@kolumbus.fi> writes:
> Strictly speaking, at least one book trying to achieve something like
> that exists:
> Hank Bromley, Richard Lamson
> Lisp Lore: A Guide to Programming the Lisp Machine
>
> The problem with that is that it isn't of much use without a Symbolics
> LispM.
I don't know; I think it is of great use--making one less likely to
be satisified with poor environments, and giving one ideas on how to
improve the one one uses. Sure, probably a poor replacement for having
a LispM around, but it's a lot easier to acquire (and lug around).
TTFN,
'mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
Edi Weitz <···@agharta.de> writes:
> [1] Well, the _real_ way to do it (at least what most people do,
> anyway) is not to start CLISP (or CMUCL, or SBCL, or OpenMCL, or
> another CL implementation) directly but from within Emacs using
> ILISP <http://sourceforge.net/projects/ilisp/> to control it.
I disagree, the _real_ way to do it is to start the implementation,
then start its editor/ide if it didn't start already. Eg:
$ cmucl
Starting /opt/local/bin/cmucl ...
CMU Common Lisp 18d, running on apocalypse.OCF.Berkeley.EDU
Send questions to ··········@cons.org. and bug reports to ·········@cons.org.
Loaded subsystems:
Python 1.0, target SPARCstation/Solaris 2
CLOS based on PCL version: September 16 92 PCL (f)
* (require :hemlock)
; Loading #p"/opt/local/packages/cmucl-18d/lib/subsystems/hemlock-library.sparcf".
;; Loading #p"/opt/local/packages/cmucl-18d/lib/subsystems/clx-library.sparcf".
T
* (ed)
But you can fake it by using Emacs/ILISP. Not that this probably
matters to the OP...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Edi Weitz <···@agharta.de> writes:
>
> > [1] Well, the _real_ way to do it (at least what most people do,
> > anyway) is not to start CLISP (or CMUCL, or SBCL, or OpenMCL, or
> > another CL implementation) directly but from within Emacs using
> > ILISP <http://sourceforge.net/projects/ilisp/> to control it.
>
> I disagree, the _real_ way to do it is to start the implementation,
> then start its editor/ide if it didn't start already. Eg:
>
> $ cmucl
> Starting /opt/local/bin/cmucl ...
> CMU Common Lisp 18d, running on apocalypse.OCF.Berkeley.EDU
> Send questions to ··········@cons.org. and bug reports to ·········@cons.org.
> Loaded subsystems:
> Python 1.0, target SPARCstation/Solaris 2
> CLOS based on PCL version: September 16 92 PCL (f)
> * (require :hemlock)
> ; Loading #p"/opt/local/packages/cmucl-18d/lib/subsystems/hemlock-library.sparcf".
> ;; Loading #p"/opt/local/packages/cmucl-18d/lib/subsystems/clx-library.sparcf".
> T
> * (ed)
>
> But you can fake it by using Emacs/ILISP. Not that this probably
> matters to the OP...
OK, let me also disagree. I think this is kind of a chicken-and-egg
problem. I definitely understand the virtues of using an editor which
is part of your CL implementation and written in the same language but
from what's currently available[1] I see a couple of shortcomings:
If you happen to use Emacs all the time (including editing other
languages than CL, reading and writing email and Usenet news, working
with CVS, and so on) every little deviation from what you're used to
can by quite disturbing. In other words, I personally think it's
easier to use something completely different than a tool that is
"almost" like Emacs because some things _are_ different and even if
you invest enough time to make your CL editor work like Emacs you
might end up with a couple of keybindings that don't do exactly the
same thing or with some functions that can't be reproduced exactly.
And even if all this would be to your liking there will come the time
where you'll want to kill a code snippet and yank it into an email
buffer which you want to send to a friend. Can Hemlock do that?
LispWorks' editor can't and this is one of many reasons why I often
use Emacs to control LW although at times it can be much more
convenient to use the LW IDE (with its process browser, inspector,
graphical debugger, etc.) instead.
This'll inevitably lead us to the old "Let's build Emacs in CL" thread
which we had often enough... :)
Edi.
[1] I'm mainly talking about the LispWorks editor and IDE and also
about MCL and Hemlock although I haven't used the latter two often
enough.
Edi Weitz <···@agharta.de> writes:
> If you happen to use Emacs all the time (including editing other
> languages than CL, reading and writing email and Usenet news, working
> with CVS, and so on) every little deviation from what you're used to
> can by quite disturbing. In other words, I personally think it's
> easier to use something completely different than a tool that is
> "almost" like Emacs because some things _are_ different and even if
> you invest enough time to make your CL editor work like Emacs you
> might end up with a couple of keybindings that don't do exactly the
> same thing or with some functions that can't be reproduced exactly.
This is a great explanation of why I don't use XEmacs. However, for
editing Lisp code, there really aren't that many commands I use
elsewhere in Emacs that aren't ancient Emacs commands (and thus in
Hemlock). With a little bit of hacking at init files, it's easy
enough to make Hemlock behave like GNU Emacs enough that it's not
distracting -- ie, all the editing commands behave the same. Sure M-x
apropos won't be the same, but by then, you're paying attention to the
fact that you're using the editor, and not what you're editing, so
it's not distracting.
> And even if all this would be to your liking there will come the time
> where you'll want to kill a code snippet and yank it into an email
> buffer which you want to send to a friend. Can Hemlock do that?
Hemlock has a mail reader, so you can use Hemlock itself to send
email, if that's what you meant. If you meant can you copy-and-paste
to/from other X apps, of course you can.
> LispWorks' editor can't and this is one of many reasons why I often
> use Emacs to control LW although at times it can be much more
> convenient to use the LW IDE (with its process browser, inspector,
> graphical debugger, etc.) instead.
I assume you mean the LW editor doesn't have a mail mode? If so, just
keep Emacs running, which I'd imagine you'd want to do for all your
other editing tasks.
> This'll inevitably lead us to the old "Let's build Emacs in CL" thread
> which we had often enough... :)
It would be really nice if one of those would just fall from the sky,
huh? (CLmacs, not the thread, which falls from the sky all the time).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 05 Apr 2003 00:59:16 +0200, Edi Weitz <···@agharta.de> wrote:
> And even if all this would be to your liking there will come the time
> where you'll want to kill a code snippet and yank it into an email
> buffer which you want to send to a friend. Can Hemlock do that?
I think so.
Paolo
--
Paolo Amoroso <·······@mclink.it>
I'm almost scared to reply to your post because I think I'm on the cusp of
understanding. So, I won't reply, I'll just say: "Ok. Thank you."
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
Edi Weitz <···@agharta.de> writes:
> ···········@aol.commune (Andrew Burton) writes:
>
> > I mean, here... if I type in:
> >
> > clisp -l -o filename -f filename.lisp (apologies if I have mangled arguments)
> >
> > ...it compiles it my program into a language the machine understands, the same
> > as if I type:
> >
> > gcc -o filename filename.c
> >
> > ...right?
>
> No, actually. The usual way to use a CL implementation is _not_ to use
> it like this (i.e. as a command line tool or as a Unix 'filter' if
> you'd like to see it like this) but to start it like
>
> clisp
>
> and then work _inside_ of it[1] - load files, change functions and
> classes on the fly, use the debugger, inspect objects, query the
> system for documentation strings, all that stuff. If you haven't done
> that you haven't really used Lisp.
>
> Edi.
>
> [1] Well, the _real_ way to do it (at least what most people do,
> anyway) is not to start CLISP (or CMUCL, or SBCL, or OpenMCL, or
> another CL implementation) directly but from within Emacs using
> ILISP <http://sourceforge.net/projects/ilisp/> to control it.
>
> Or, if you use a commercial CL implementation like LispWorks,
> AllegroCL, or MCL, you'll probably use their IDE instead of Emacs
> but it boils down to the same thing: You usually don't ask a
> compiler to compile a static source file but instead you interact
> with a 'listener' which provides a 'read-eval-print loop' (REPL)
> to help you to interactively develop, test, and debug your
> applications.
>
> You shouldn't compare Lisp to other languages until you've grasped
> these basic concepts. A book might help...
Which book? I am specifically looking for how to work inside lisp as
opposed to writing lisp per se. Like you say, use the debugger,
inspect objects, query the system, patch at runtime &c. I am using
emacs/ilisp with clisp and sometimes cmucl but only in a rather
rudimentary way. This is obviously implementation dependent. Perhaps
a commercial implementation would be much better?
I can load/compile files with C-z l, or just compile with C-z k.
I evan expressions with C-z e. When i get in the break loop (with
clisp) i can type :a. But I am thinking I am missing so much more.
--
Johan KULLSTAM <··········@attbi.com> sysengr
In the last exciting episode, Tim Bradshaw <···@cley.com> wrote:
> * Andrew Burton wrote:
>> So, yes, clisp is like gcc or Delphi, it's the compiler.
>
> No, it really isn't like them. But never mind, if you haven't
> understood this far, you probably never will.
While it is not /precisely/ parallel, I don't think it is unreasonable
to consider them parallel.
CLISP is an implementation of a CL compiler, much as GCC is an
instance of a C compiler. LCC is another C compiler; CMU/CL is
another CL implementation.
There's certainly more to things than that; a CL implementation
comprises more components than just a compiler. With CMU/CL, the
"compiler," called Python, is a fairly /small/ portion of the overall
system. Add to that components that, with other languages, would be
called "libraries," and the notion of "runtime support" that, while
often invisible to C programmers, is nonetheless necessary /even in
C/.
It seems more reasonable to me to explain that rather than to poke at
someone as being too stupid to grasp differences.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/internet.html
"If you were plowing a field, which would you rather use? Two strong
oxen or 1024 chickens?" -- Seymour Cray
On 30 Mar 2003 23:20:34 GMT, ···········@aol.commune (Andrew Burton) wrote:
> see if I finally got this right: Comon Lisp is the language, like C or Pascal.
> CLisp is the compiler, like gcc or Delphi (an IDE, I know). When discussing
> Common Lisp, type "Common Lisp" or "CL" in sentences. When discussing the
> program, type "CLisp" or "clisp" in the sentence?
>
> Is that it?
Yes.
Paolo
--
Paolo Amoroso <·······@mclink.it>
On 30 Mar 2003 21:44:13 GMT, ···········@aol.commune (Andrew Burton) wrote:
> I think it came from http://clisp.cons.org -- I think. While I have your ear,
> where can I find a page that gives the full (and seemingly sordid) family tree
> of Lisp? I know there was Lisp once, bourne of a mathematician cum Fortran
This paper by Steele and Gabriel provides the gory details:
The Evolution of Lisp
ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/Evolution-of-Lisp.ps.gz
Paolo
--
Paolo Amoroso <·······@mclink.it>
Thanks!
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!