Which one, Lisp or Scheme?

89 views
Skip to first unread message

Yunho Jeon

unread,
Jan 20, 1997, 3:00:00 AM1/20/97
to

Hello,
I have some idea to experiment with, and the idea needs a language which can
execute codes produced by the program itself. Naturally, I thought LISP would
be the best choice. But while reading LISP FAQ, I found that there are
some varients of the language. Notably, Scheme seemed to be more modern and
cleaner language than LISP. Because I have almost no experience in those
languages, I would like to get answers from LISP/Scheme experts
for the following questions.

1) Which language is easier to learn (for C/C++ programmer)?
Scheme seems to be easier because it is much smaller than common lisp,
but how big is the difference (in terms of learning curve)?

2) The command to parse and execute a source program is 'eval', right?
If it is, is it a standard feature of Scheme? The Scheme FAQ was not
very clear on this point. Surely some implementations have it, but
the language seems to be more suited for compilers. Does the run-time
has embedded compiler? What's the overhead of it (size/speed)?
If I can't use compiler for my purposes, what do I lose and how much
(again in terms of speed)?

3) What about foreign language (C/C++) language interface and GUI's?
It's not essential for now, but it may be needed in future.

4) I am going to use Linux as the experiment platform, and don't want to
buy any commercial software - I'm only a student and it's hard to buy
and get support of such a software in Korea, where I live.
Both language has a lot of free implementations, but are they mature
enough?

Thanks for any helps in advance.
Best regards,
------------------------------------------------------------------------------
Yunho Jeon Tel: +82-2-880-6482~90 ext) 416
Intelligent Control Lab +82-2-875-9183
School of Electrical Engineering Fax: +82-2-888-4182
Seoul National University, Korea Email: yu...@csl.snu.ac.kr


Rainer Joswig

unread,
Jan 20, 1997, 3:00:00 AM1/20/97
to

> 1) Which language is easier to learn (for C/C++ programmer)?
> Scheme seems to be easier because it is much smaller than common lisp,
> but how big is the difference (in terms of learning curve)?

Common Lisp comes with a larger library, has some rough edges,
is more "industrial strength", ...

Scheme is much smaller, has some very different implementations,
has a lot of non-standard extensions, ..

Both Common Lisp and Scheme basics are relatively easy to learn.

> 2) The command to parse and execute a source program is 'eval', right?

Common Lisp has "READ", "EVAL" and "COMPILE".

> If it is, is it a standard feature of Scheme? The Scheme FAQ was not
> very clear on this point.

EVAL is not a standard feature of Scheme. Still, most Scheme systems
have it.

> 3) What about foreign language (C/C++) language interface and GUI's?
> It's not essential for now, but it may be needed in future.

FFI and GUI functionality is available. But no standard in sight.


> 4) I am going to use Linux as the experiment platform, and don't want to
> buy any commercial software - I'm only a student and it's hard to buy
> and get support of such a software in Korea, where I live.
> Both language has a lot of free implementations, but are they mature
> enough?

You may want to use Allegro CL 4.3 from Franz Inc. for Linux.
It is ***free*** for non commercial use. ACL 4.3 should be mature enough. ;-)
See http://www.franz.com/ how to get it. Got my CD-ROM (thanks Franz!,
but haven't tried it yet.


Rainer Joswig

Jussi Mantere

unread,
Jan 20, 1997, 3:00:00 AM1/20/97
to

Yunho Jeon (yu...@csl.snu.ac.kr) wrote:
: 2) The command to parse and execute a source program is 'eval', right?
: If it is, is it a standard feature of Scheme? The Scheme FAQ was not
: very clear on this point. Surely some implementations have it, but

: the language seems to be more suited for compilers. Does the run-time
: has embedded compiler? What's the overhead of it (size/speed)?
: If I can't use compiler for my purposes, what do I lose and how much
: (again in terms of speed)?
You're thinking way too C here.
When you install a Scheme (or any LISP) package on your computer,
you install the _interpreter_, or evaluator.
If you run the interpreter and type any command or procedure, the
evaluator automatically evaluates it and displays whatever value it's
supposed to display.

So, a "source program" is actually just a huge procedure which you'll execute
like any command.

(eval <op> <env>) as such is, afaik, a standard feature in scheme, defined in
R4RS. It evaluates whatever you feed to it in a given environtment.

See SICP for more info;)


: 4) I am going to use Linux as the experiment platform, and don't want to


: buy any commercial software - I'm only a student and it's hard to buy
: and get support of such a software in Korea, where I live.
: Both language has a lot of free implementations, but are they mature
: enough?

They are mature enough. Don't buy anything commercial.
Use Emacs and whatever scheme implementation you find convenient.
Guile, MIT Scheme... whatever.

-obs
--
(define me '((jussi mantere) (jmt 6b112a 02150 espoo) (09-468 2718)
(o...@iki.fi) (http://www.iki.fi/~obs)
(TiK abilobbari '97)))
Mikä Ihmeen Tiainen? Saakeli Cun Häiritsee - En Muista Enää!

Thant Tessman

unread,
Jan 20, 1997, 3:00:00 AM1/20/97
to

Yunho Jeon wrote:

> I have some idea to experiment with, and the idea needs a language which can

> execute codes produced by the program itself. [...]

> 2) The command to parse and execute a source program is 'eval', right?

Yes, but it's probably not what you need. The magical part of Scheme is
"lambda" which is how functions build other functions.

Actually, Scheme contains three levels of enlightenment. The first is
higher-order functions (lambda). The second is continuations
(call-with-current-continuation), and the third is macros.

Each will thoroughly hurt your brain, but re-birth is a painful process.
If you persevere you will be transformed, thrice, into a higher being.

-thant

Howard R. Stearns

unread,
Jan 20, 1997, 3:00:00 AM1/20/97
to

Yunho Jeon wrote:
>
> Hello,

> I have some idea to experiment with, and the idea needs a language which can
> execute codes produced by the program itself. Naturally, I thought LISP would
> be the best choice. But while reading LISP FAQ, I found that there are
> some varients of the language. Notably, Scheme seemed to be more modern and
> cleaner language than LISP. Because I have almost no experience in those
> languages, I would like to get answers from LISP/Scheme experts
> for the following questions.
> ...
> 2) The command to parse and execute a source program is 'eval', right?
> ...

Sort of.

The function READ parses information from a character stream and creates
lisp data (lists of literals, symbols, and more lists) that represent
the program "text".

The function EVAL can be used to execute such data as a program. EVAL
does not operate on characters, strings or streams.

In practice, EVAL is usually not necessary. In my experience, EVAL is
used in most textbooks only in discussing the implementation of an
interpreter (for Lisp or some other language). This is NOT the only way
to have a program execute utilities that are produced by the program
itself. Most projects are more cleanly and efficiently written using
compiled closures.

Will Hartung

unread,
Jan 20, 1997, 3:00:00 AM1/20/97
to

yu...@csl.snu.ac.kr (Yunho Jeon) writes:

>Hello,
>I have some idea to experiment with, and the idea needs a language which can
>execute codes produced by the program itself. Naturally, I thought LISP would
>be the best choice. But while reading LISP FAQ, I found that there are
>some varients of the language. Notably, Scheme seemed to be more modern and
>cleaner language than LISP. Because I have almost no experience in those
>languages, I would like to get answers from LISP/Scheme experts
>for the following questions.

I'm no expert, but that hasn't stopped me before.

>1) Which language is easier to learn (for C/C++ programmer)?
> Scheme seems to be easier because it is much smaller than common lisp,
> but how big is the difference (in terms of learning curve)?

Frankly, I would say that Lisp would be easier to learn than Scheme
for an C/C++ programmer.

Scheme is a lovely, elegant language, and is, I believe simpler and
easier to learn in its own right. It is hard not to like Scheme. But,
for someone who has a lot of history with C/C++, the way Scheme is
presented could throw you for a loop. You, as the student, would
probably take the approach of trying to learn "Scheme Syntax", whereas
the books spend more time on the "Scheme Way".

The "Scheme Way" of programming is very functional, lots of recursion,
local helper functions, etc. It is really a pretty nice way to go
about task of coding. However, its not the way MOST people
(particularly C/C++ people) write code. The idioms are all wrong.

If you look at how Lisp is presented, especially in something like
Paul Grahams "ANSI Common Lisp" book, it is easier to see the how your
entrenched C/C++ idioms translate into Lisp syntax and structures.

Once you get past the hurdles of the fact that you don't need pointers,
its pretty easy to write C/C++ code in a Lisp syntax. And Common Lisp
has an enormous catalog of functions to do all sorts of things. All of
the structures you are used to are in the language.

If you want to change the way to think about progamming and problem
solving, then grab all of the Scheme books, dig in, strap yourself
down, and hang on for a wild ride. It's quite a trip.

If you just want to work on your task, using your current mindset,
then get into Common Lisp, and let your fingers do the talking. You can
treat CL like C/C++ a lot easier. However, I do suggest you go in with
an open mind for the new, more powerful ways of solving problems that CL
can provide for you.

>2) The command to parse and execute a source program is 'eval', right?

> If it is, is it a standard feature of Scheme? The Scheme FAQ was not
> very clear on this point. Surely some implementations have it, but
> the language seems to be more suited for compilers. Does the run-time
> has embedded compiler? What's the overhead of it (size/speed)?
> If I can't use compiler for my purposes, what do I lose and how much
> (again in terms of speed)?

'eval' is standard in CL, not standard in Scheme, but as has been
mentioned, many Schemes provide it. 'eval' can incur a pretty dramatic
hit on the execution size of a program. How much overhead depends on
the implementation.

>3) What about foreign language (C/C++) language interface and GUI's?
> It's not essential for now, but it may be needed in future.

Many systems provide foriegn function interfaces. GUI's are available,
though less prominent.

>4) I am going to use Linux as the experiment platform, and don't want to
> buy any commercial software - I'm only a student and it's hard to buy
> and get support of such a software in Korea, where I live.
> Both language has a lot of free implementations, but are they mature
> enough?

There are several systems available for Linux. The FAQ lists most of
them. I like Aubrey Jaffers SCM Scheme package, and the latest Gambit-C
2.2 Scheme compiler getting a lot of good press. Scheme packages
differ wildly, so check the details.

There is a lot of "real" work going on in many of these packages, and
most are very mature.

Good Luck!

--
Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck

Erik Naggum

unread,
Jan 21, 1997, 3:00:00 AM1/21/97
to

* Jussi Mantere

| When you install a Scheme (or any LISP) package on your computer,
| you install the _interpreter_, or evaluator.

this is factually wrong.

| (eval <op> <env>) as such is, afaik, a standard feature in scheme,
| defined in R4RS.

this is factually wrong.

| They are mature enough. Don't buy anything commercial.
| Use Emacs and whatever scheme implementation you find convenient.
| Guile, MIT Scheme... whatever.

this is disquieting. the strongest effects of free Lisp implementations to
date have been to turn people away from Lisp due to low performance, high
memory usage, etc; to perpetrate the _myth_ that all Lisps are interpreted,
that the language is slow, etc; to make people believe that Lisps don't fit
in with the rest of the operating system, that you can't make executables;
etc ad nauseam.

commercial implementations have taken Lisps out of the experimental lab and
made them shippable and supportable as useful systems. apparently, the
discipline needed to do this is not available for free, so it is safe to
assume it is hard, mostly uninspiring, work. (note, however, that my
experience is with Common Lisp. I don't know Scheme very well.)

#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.

aro...@momotombo.austin.ibm.com

unread,
Jan 21, 1997, 3:00:00 AM1/21/97
to

Thant Tessman wrote:
> Actually, Scheme contains three levels of enlightenment. The first is
> higher-order functions (lambda). The second is continuations
> (call-with-current-continuation), and the third is macros.

Let's rename Scheme 'Scheme Trismegistus'.

Chris Bitmead

unread,
Jan 22, 1997, 3:00:00 AM1/22/97
to

In article <30627981...@naggum.no> Erik Naggum <er...@naggum.no> writes:

>| They are mature enough. Don't buy anything commercial.
>| Use Emacs and whatever scheme implementation you find convenient.
>| Guile, MIT Scheme... whatever.
>
>this is disquieting. the strongest effects of free Lisp implementations to
>date have been to turn people away from Lisp due to low performance, high
>memory usage, etc; to perpetrate the _myth_ that all Lisps are interpreted,
>that the language is slow, etc; to make people believe that Lisps don't fit
>in with the rest of the operating system, that you can't make executables;
>etc ad nauseam.
>
>commercial implementations have taken Lisps out of the experimental lab and
>made them shippable and supportable as useful systems. apparently, the
>discipline needed to do this is not available for free, so it is safe to
>assume it is hard, mostly uninspiring, work. (note, however, that my
>experience is with Common Lisp. I don't know Scheme very well.)

There are free Scheme and Lisp compilers capable of producing binary
executables. So you don't need a commercial product. (Although I'm
sure Franz lisp is an excellent product).

Erik Naggum

unread,
Jan 22, 1997, 3:00:00 AM1/22/97
to

* Chris Bitmead

| There are free Scheme and Lisp compilers capable of producing binary
| executables. So you don't need a commercial product. (Although I'm sure
| Franz lisp is an excellent product).

it may say more about my experience than anything else, but I grabbed all
the (free) Common Lisp implementations I could get my hands on for my
SPARC, including akcl, gcl, wcl, clisp, cmucl, and since I didn't have any
experience from any "real" Lisp systems, didn't know what I misssed outside
of CLtLn (n = 1 (akcl, gcl, wcl) or 2 (clisp, cmucl)). I don't want to go
advertising any products, but when I got my first commercial Lisp system
six weeks ago, I stopped working on my (Lisp) projects and sat down to
learn the _rest_ of the Lisp systems, as documented in about 1200 pages.
this has indeed paid off _very_ handsomely, yet it tells me that if all you
have ever seen are the free Lisps, you might be in for a very big surprise
when you get a Lisp-machine-like commercial implementation of Lisp.

(however, I might easily have missed similar software for free Lisps -- I
didn't know what to look for. maybe it would be useful if somebody who
knows what to look for in each compared free and commercial Lisp?)

Martin Cracauer

unread,
Jan 23, 1997, 3:00:00 AM1/23/97
to

Erik Naggum <er...@naggum.no> writes:

>| They are mature enough. Don't buy anything commercial.
>| Use Emacs and whatever scheme implementation you find convenient.
>| Guile, MIT Scheme... whatever.

>this is disquieting. the strongest effects of free Lisp implementations to
>date have been to turn people away from Lisp due to low performance, high
>memory usage, etc; to perpetrate the _myth_ that all Lisps are interpreted,
>that the language is slow, etc; to make people believe that Lisps don't fit
>in with the rest of the operating system, that you can't make executables;
>etc ad nauseam.

CMUCL is as fast and even smaller than most commercial implementations
on Unix. The only things I miss are threads and a better garbage
collector (although CMUCL's superior warnings help not to produce as
much gargabe in first place).

A commercial implementation has a nice environment, nice browsers,
maybe an editor in Common Lisp and therefore controllable from Lisp
and I found it very valuable to have such a visualization toolkit
around when I learned Common Lisp. But I think Eric missed the point
here.

I agree with the point that many free Lisp implementations are slow
and fail to point out in their documentation that one can run the same
program faster. In fact, I already had an argument with the author of
Xlisp about it after some magazine compared Lisp and perl (that is
Xlisp and perl) and headlined that Lisp is slow.

The problem here is that people choose a free implementation by other
criteria than speed and then complain it is too slow because they
underestimated the amount of efficiency they give up.

The Scheme community with eval implemented as write/read to disk
sometimes and total lack of declarations, but implementations that
take numbers as 32bit-limited without programmers permission is
another issue. While the author is not responsible, slib was what
turned me away from Scheme rather quickly. Some slib functionality in
unbeleivable slow in many implementation, functionality that is
standard in Common Lisp and Perl and therefore implemented either in C
or as overhead-free, declared code.

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin_...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin

Erik Naggum

unread,
Jan 24, 1997, 3:00:00 AM1/24/97
to

* Martin Cracauer

| CMUCL is as fast and even smaller than most commercial implementations on
| Unix. The only things I miss are threads and a better garbage collector
| (although CMUCL's superior warnings help not to produce as much gargabe
| in first place).

ah, agreed, but CMUCL is a breed apart from the rest. it compiles to
native code directly for a number of platforms, which is a formidable task,
and it is exceptionally good at helping the programmer declare types of
values when it could have used a hint. the code it generates is also quite
good. however, this is not the norm for free Lisp implementations.

out of the several hundred free Lisps and Schemes out there, most are toys.
they may be fun toys, but they are still toys. I think this is because it
is so easy to write a toy Lisp or Scheme, and so hard to write a fully
functional Lisp system.

| A commercial implementation has a nice environment, nice browsers, maybe
| an editor in Common Lisp and therefore controllable from Lisp and I found
| it very valuable to have such a visualization toolkit around when I
| learned Common Lisp. But I think Eric missed the point here.

well, those have been immaterial to me, but I'm sure we meet different
aspects of Lisp systems according to our experience. I have never used a
real Lisp system for real until I got Allegro CL, so I was impressed by how
much the system knew about itself, how much time the source code manager
saved me, how well the debugging is integrated with the cross-referencing
utilities, etc. example: I have about 200 functions in a package I'm
writing, spread across several files, and I can ask who calls a given
function, directly or indirectly. I know which functions and files to
recompile after changing a macro by asking for who uses it. I can ask the
system to tell me which functions bind, set, and/or reference a variable.
I have needed this functionality for _years_, not just in Lisp. Allegro
also has search lists that can do wondrous things, too. it's everything
_outside_ of the common Common Lisp stratum that impresses me most.

| In fact, I already had an argument with the author of Xlisp about it
| after some magazine compared Lisp and perl (that is Xlisp and perl) and
| headlined that Lisp is slow.
|
| The problem here is that people choose a free implementation by other
| criteria than speed and then complain it is too slow because they
| underestimated the amount of efficiency they give up.

I see a possible pattern here. if C was slow on some machine or in some
particular implementation, nobody would blame C or headline that C is slow.
the myth is that Lisp is slow, and every time somebody meets a slow Lisp,
that myth is reinforced. that you can compile with CMUCL at high speed
settings and beat the sh*t out of C is just as much as an aberration as C
running under some bounds-checking and memory-tracking package is slow.

yes, we all know that Lisp can be incredibly fast. we all know that Scheme
can be statically typed, too, as in the Stalin compiler. neither changes
the naive perceptions and the myths that will be reinforced the next time a
small, neat, fun toy, somewhat like SIOD, is released and tested by
somebody who carries those myths with him.

that's how I meant that the free Lisps have mostly worked to turn people
away from Lisp. I didn't mean that you can't find free Lisps that people
would have flocked to if they would only get over their prejudices. I
meant that they don't, because of the many toys they have used and think
are the norm. it seems, for instance, that in educational settings, Lisp
and Scheme are not at all presented with anything resembling speed in mind,
and so students who are used to C and C++ and ads reading "X compiles Java
at over 10,000 lines per second", will have trouble _not_ remembering that
speed was never discussed, that their compilers and interpreters were slow,
etc, etc. I mean, we have people come in here and state that Lisp is an
interpreted language at least once a week! it's an image problem, and it's
a tragic element of that story that as Lisp implementers focus on other
things, students and amateur programmers are turned into speed fanatics
because that is the only forte of those other languages and systems. (and
never mind that Allegro CL for Linux produces code that runs rings around
C++ under Windows NT on the same machine. *sigh*)

Marco Antoniotti

unread,
Jan 24, 1997, 3:00:00 AM1/24/97
to

I am enjoying this thread and I believe that it would be helpful to do
some classification in the Lisp/Scheme field and to produce some
"advice paper" (or whatever you want to call it.) Any magazine
article which wouldn't refer to such a pamphlet (as the aforemetioned
Lisp vs. Perl bogus comparison) should immediatly be dismissed with
for lack of parenthesis :)

First of all (and here I already know, there will be chaos) there are
only three dialects to be considered.

Common Lisp
Emacs Lisp (which, btw. can always be turned almost to a CLtL1 by
(require 'cl))
Scheme

Xlisp claims to be more and more CL (at least CLtL1) compliant.
Therefore it should not be considered as a standalone dialect.

Now we list the only reasonable alternatives for a free (gratis)
Common Lisp implementation and rank them for speed.

1 - CMUCL (Sparc, HP-PA, MIPS, X86)
4 - GCL, ECL (most Unix flavors and architectures - KCL and AKCL
are *OLD*)
5 - CLISP (Sorry Bruno! :) )
6 - Xlisp

The gap is intended :) (even if it may not be as wide as I'd like) The
latest version of Allegro CL for Linux is free, but who knows what
will be the marketing policies of Franz Inc.

In the Scheme world, though I never tried it, I hear that the Stalin
compiler could be a 1 or a 2 in my previous scale. AFAIK all the
other Scheme's (apart from being incompatible from each other at some
level) rank at 6 OR WORSE.

Emacs Lisp is reasonably fast and I would rank it 5.

In the commercial field, it looks like there are only three
alternatives for Common Lisp and their relative speed in my modest
experience would be the following.

1/2 Lucid (Un*x)
2/3 ACL, LispWorks (Un*x)
2/3 MCL (MacOS)

I left out Genera/Symbolics because it is in a league of its own. And
I am not familiar with any of the other (if surviving) commercial CL
implementations.

I have not been using ACL/PC enough to have a good idea of it, but the
environment sure looks as appealing as the fantastic MCL on the Mac
(of which I am a big fan :) )

--
Marco Antoniotti - Resistente Umano
===============================================================================
...it is simplicity that is difficult to make.
Bertholdt Brecht

Michael Sperber [Mr. Preprocessor]

unread,
Jan 24, 1997, 3:00:00 AM1/24/97
to

>>>>> "DB" == David Betz <db...@xlisper.mv.com> writes:

DB> [ ... ] If Lisp is going to be compared with
DB> other languages for speed, it should be the commercial implementations
DB> that are used in the comparison. (Although perl isn't commercial as far
DB> as I know.)

Still, there are free implementations of Scheme that are *VERY* fast.
Both Gambit and Bigloo can actually compete with C on at least some
applications. I'd be suprised if, say, Chez Scheme, were
significantly faster.

Cheers =8-} Mike


Guillermo (Bill) J. Rozas

unread,
Jan 24, 1997, 3:00:00 AM1/24/97
to

In article <30631029...@naggum.no> Erik Naggum <er...@naggum.no> writes:

| From: Erik Naggum <er...@naggum.no>
| Date: 24 Jan 1997 13:56:07 +0000

| that's how I meant that the free Lisps have mostly worked to turn people
| away from Lisp. I didn't mean that you can't find free Lisps that people
| would have flocked to if they would only get over their prejudices. I
| meant that they don't, because of the many toys they have used and think
| are the norm. it seems, for instance, that in educational settings, Lisp
| and Scheme are not at all presented with anything resembling speed in mind,
| and so students who are used to C and C++ and ads reading "X compiles Java
| at over 10,000 lines per second", will have trouble _not_ remembering that
| speed was never discussed, that their compilers and interpreters were slow,
| etc, etc. I mean, we have people come in here and state that Lisp is an
| interpreted language at least once a week! it's an image problem, and it's
| a tragic element of that story that as Lisp implementers focus on other
| things, students and amateur programmers are turned into speed fanatics
| because that is the only forte of those other languages and systems. (and
| never mind that Allegro CL for Linux produces code that runs rings around
| C++ under Windows NT on the same machine. *sigh*)

Actually, I think that the speed of the implementation, although
important, is nowhere near as critical as other components.

Lisp/Scheme gives you so much rope that it is so much easier to hang
yourself with, especially with respect to performance.

There is an old adage that goes something like "Lisp programmers know
the value of everything and the cost of nothing", and I think that it
is very true.

I have seen people complain about slow implementations only to
discover quadratic algorithms because they were treating lists as
arrays, or some other similar problem. Because C lacks lists, they
would never have written the program that way. Even if they used
lists, they would have to implement list-ref and list-set! themselves,
and would immediately realize how expensive they are, so they would
rethink their strategy.

Three issues that help C in efficiency (in my view) are:

- Good efficiency model in the small. It is very clear without much
thought to most C programmers how expensive or cheap the primitive
operations are. As a counterpart, the cost of closures and
continuations in Lisp/Scheme (and even simple addition) is much harder
to tell (even by an experienced programmer) because they depend so
much more on how well the compiler was able to optimize the code,
leading to small transformations affecting performance in
non-negligible ways.

- The standard library in C is very small. Thus C programmers reinvent
the wheel (hash tables, etc.) over and over in their programs. In so
doing, the cost of these operations (which might be primitives in
Lisp/Scheme) becomes painfully obvious to them, so they use them much
more judiciously than they might if given to them freely.

- Compilers still largely compile Fortran-style code much better than
small-procedure-intensive code. In as much as the prevailing
programming style in C is closer to Fortran than it is to Scheme's
preferred style, the performance of the code will be better. Remember
that most data flow algorithms (and so-called "global" optimizations)
work within procedures. Register allocation and instruction
scheduling are understood (to the degree they are) only within
procedures, etc. There is just not that much that a compiler can do
(short of inlining which is difficult with computed function calls) if
the procedures are really small. Lisp/Scheme compilers try to do a
good job at procedure calls, often better than C/Fortran, but they
can't generally compensate for bad style (with respect to efficiency
if not modularity and elegance). That is why it is not unusual to
find that a Lisp/Scheme compiler will beat some C compiler in
Fibonacci, Tak, or some such, but not in a more realistic programs.

Scott Draves

unread,
Jan 24, 1997, 3:00:00 AM1/24/97
to

David Betz <db...@xlisper.mv.com> wrote

> If Lisp is going to be compared with

> other languages for speed, it should
> be the commercial implementations

why? there are plenty of free&fast
implementations of *both* C (GCC, LCC)
and Lisp/scheme (CMUCL, gcl, gambit, cscheme).

--
balance
equilibrium
death

http://www.cs.cmu.edu/~spot

Juergen Nickelsen

unread,
Jan 25, 1997, 3:00:00 AM1/25/97
to

Marco Antoniotti <mar...@crawdad.icsi.berkeley.edu> wrote:

> Emacs Lisp (which, btw. can always be turned almost to a CLtL1 by
> (require 'cl))

While Emacs Lisp is perhaps the most widespread Lisp dialect (with most
of its users unaware of its existence), I would not consider it one of
the major Lisp dialects -- its scope (no pun intended) is just too
small.

cl.el does not turn Emacs Lisp into a CLtL1 Lisp. It does provide some
of the convenience functions like caadr, backquote and comma (but as
macros, not reader macros, like in "(` (3 4 (, (+ 5 6)) 7)))", and some
other.

--
Juergen Nickelsen

Erik Naggum

unread,
Jan 26, 1997, 3:00:00 AM1/26/97
to

* Juergen Nickelsen

| cl.el does not turn Emacs Lisp into a CLtL1 Lisp. It does provide some
| of the convenience functions like caadr, backquote and comma (but as
| macros, not reader macros, like in "(` (3 4 (, (+ 5 6)) 7)))", and some
| other.

I'm getting _real_ sick and tired of old prejudice against various Lisps.

next time, check your facts with a recent Emacs. the backquote package was
completely rewritten 1994-03-06. that's nearly three years ago! the Lisp
reader now accepts both the old and the new style equally well.

*sigh*

Juergen Nickelsen

unread,
Jan 26, 1997, 3:00:00 AM1/26/97
to

By mistake (I was too stupid to handle my newsreader) I posted the
following before the article was complete:

> Marco Antoniotti <mar...@crawdad.icsi.berkeley.edu> wrote:
>
> > Emacs Lisp (which, btw. can always be turned almost to a CLtL1 by
> > (require 'cl))
>
> While Emacs Lisp is perhaps the most widespread Lisp dialect (with most
> of its users unaware of its existence), I would not consider it one of
> the major Lisp dialects -- its scope (no pun intended) is just too
> small.
>

> cl.el does not turn Emacs Lisp into a CLtL1 Lisp. It does provide some
> of the convenience functions like caadr, backquote and comma (but as
> macros, not reader macros, like in "(` (3 4 (, (+ 5 6)) 7)))", and some
> other.

To be precise, it adds a lot of convenience functions, and this is what
is intended by cl.el. Its author Dave Gillespie writes in the cl.el
documentation:

> * Some features are too complex or bulky relative to their benefit
> to Emacs Lisp programmers. CLOS and Common Lisp streams are fine
> examples of this group.
>
> * Other features cannot be implemented without modification to the
> Emacs Lisp interpreter itself, such as multiple return values,
> lexical scoping, case-insensitive symbols, and complex numbers.
> The "CL" package generally makes no attempt to emulate these
> features.

cl.el does indeed make Emacs Lisp programming easier for programmers
familiar with Common Lisp. Emacs Lisp with cl.el loaded is still way
different from Common Lisp, though.

--
Juergen Nickelsen

Juergen Nickelsen

unread,
Jan 26, 1997, 3:00:00 AM1/26/97
to

Erik Naggum <er...@naggum.no> wrote:

> * Juergen Nickelsen


> | cl.el does not turn Emacs Lisp into a CLtL1 Lisp. It does provide some
> | of the convenience functions like caadr, backquote and comma (but as
> | macros, not reader macros, like in "(` (3 4 (, (+ 5 6)) 7)))", and some
> | other.

[...]


> the backquote package was completely rewritten 1994-03-06. that's nearly
> three years ago! the Lisp reader now accepts both the old and the new
> style equally well.

Please apologize for this error, it is true that I didn't follow
developments of Emacs closely.

But that did only seem like my major point here; in fact I wanted to
write more (and did in a follow-up article), but due to a mistake the
article slipped out too early. In the follow-up I quote Dave Gillespie,
recent cl.el's author, from the documentation of cl.el (as contained in
XEmacs 19.14), which states clearly the facts why cl.el does not turn
Emacs Lisp into Common Lisp.

--
Juergen Nickelsen

Martin Cracauer

unread,
Jan 26, 1997, 3:00:00 AM1/26/97
to

Erik Naggum <er...@naggum.no> writes:

>* Martin Cracauer


>| A commercial implementation has a nice environment, nice browsers, maybe
>| an editor in Common Lisp and therefore controllable from Lisp and I found
>| it very valuable to have such a visualization toolkit around when I
>| learned Common Lisp. But I think Eric missed the point here.

>well, those have been immaterial to me, but I'm sure we meet different
>aspects of Lisp systems according to our experience. I have never used a
>real Lisp system for real until I got Allegro CL, so I was impressed by how
>much the system knew about itself, how much time the source code manager
>saved me, how well the debugging is integrated with the cross-referencing
>utilities, etc. example: I have about 200 functions in a package I'm
>writing, spread across several files, and I can ask who calls a given
>function, directly or indirectly. I know which functions and files to
>recompile after changing a macro by asking for who uses it. I can ask the
>system to tell me which functions bind, set, and/or reference a variable.
>I have needed this functionality for _years_, not just in Lisp. Allegro
>also has search lists that can do wondrous things, too. it's everything
>_outside_ of the common Common Lisp stratum that impresses me most.

Again, I think the difference between commercial and free
implementations is not so much that free implementations don't offer
such functionality, but that all this nice functionality is offered in
a very easy way. Tools like this are availiable for example in Mark
Kantrowitz' (spelling?) tools. Since many people what to design their
own tools -maybe for severl implementations, the availiable source for
free tools can become even more important.

As I stated earlier, I think it can be very important for a new user
to have such functionality offered without further thinking and
therefore to be free to concentrate on languages issues. This is at
least where I found my commercial implementation useful (Lispworks).

I think the most important thing the free commercial Lisp for Windows
and ACL for Linux is that new Common Lisp user get a much better
chance to become productive in Common Lisp before they give up.

Later, I found CMUCL and free tools not to be second rate anymore.

Comfortable CLOS browsing is another issue when talking about free
alternatives, though.

>| In fact, I already had an argument with the author of Xlisp about it
>| after some magazine compared Lisp and perl (that is Xlisp and perl) and
>| headlined that Lisp is slow.
>|
>| The problem here is that people choose a free implementation by other
>| criteria than speed and then complain it is too slow because they
>| underestimated the amount of efficiency they give up.

>I see a possible pattern here. if C was slow on some machine or in some
>particular implementation, nobody would blame C or headline that C is slow.
>the myth is that Lisp is slow, and every time somebody meets a slow Lisp,
>that myth is reinforced. that you can compile with CMUCL at high speed
>settings and beat the sh*t out of C is just as much as an aberration as C
>running under some bounds-checking and memory-tracking package is slow.

>yes, we all know that Lisp can be incredibly fast. we all know that Scheme
>can be statically typed, too, as in the Stalin compiler. neither changes
>the naive perceptions and the myths that will be reinforced the next time a
>small, neat, fun toy, somewhat like SIOD, is released and tested by
>somebody who carries those myths with him.

In my opinion, the problem is that many Lisp and especially Scheme
tool implementors couple their tools to an inefficient
implementation. No C programmer would do so.

Of course, many Scheme tools require extending the language, whereas C
tools usually can force the programmer to use clumsy interfaces.

But I think Lisp and especially Scheme tools implementors overrated
language elegancy and gave up intergrating their tools into the best
availiable language implmentation too early.


>that's how I meant that the free Lisps have mostly worked to turn people
>away from Lisp. I didn't mean that you can't find free Lisps that people
>would have flocked to if they would only get over their prejudices. I
>meant that they don't, because of the many toys they have used and think
>are the norm. it seems, for instance, that in educational settings, Lisp
>and Scheme are not at all presented with anything resembling speed in mind,
>and so students who are used to C and C++ and ads reading "X compiles Java
>at over 10,000 lines per second", will have trouble _not_ remembering that
>speed was never discussed, that their compilers and interpreters were slow,
>etc, etc. I mean, we have people come in here and state that Lisp is an
>interpreted language at least once a week! it's an image problem, and it's
>a tragic element of that story that as Lisp implementers focus on other
>things, students and amateur programmers are turned into speed fanatics
>because that is the only forte of those other languages and systems. (and
>never mind that Allegro CL for Linux produces code that runs rings around
>C++ under Windows NT on the same machine. *sigh*)

I think it's not *that* bad.

In my opinion, people tend to rate Lisp as interpreted because they
can't get the idea of a dynamic language that is compiled. They hear
of Lisp features and automatically say "interpreted" where they may
have thought "dynamic".

In other words, the problem is not a bad image of Lisp, but the fact
that people are ignorant and tend to fail to recognize what
performance problems are really involved with a dynamic language.

Georg Bauer

unread,
Jan 26, 1997, 3:00:00 AM1/26/97
to

Hi!

MA> AFAIK all the
MA> other Scheme's (apart from being incompatible from each other at some
MA> level) rank at 6 OR WORSE.

Wrong. Many Scheme-Implementations are quite fast. And most of them
implement R4RS, so you have a standard. Ok, PC-Scheme in it's two flavours
only implements R3RS. My favorites with Scheme are Gambit-C and S88. The
first is a highly portable implementation that delivers good performance,
the latter one is a special DOS-version with native code compiler, and a
_very_ good performance. S88 is so fine because it runs on my little
Quaderno (sub-notebook computer). :-)

bye, Georg

--
Nachricht von Mausefalle

Alexey Goldin

unread,
Jan 27, 1997, 3:00:00 AM1/27/97
to

crac...@wavehh.hanse.de (Martin Cracauer) writes:
>
> Comfortable CLOS browsing is another issue when talking about free
> alternatives, though.
>


OOBR (object oriented browser) for Emacs/Xemacs helps a lot. It comes
with Xemacs distribution, but works with Emacs too.

Cyber Surfer

unread,
Jan 27, 1997, 3:00:00 AM1/27/97
to

In article <30631029...@naggum.no> er...@naggum.no "Erik Naggum" writes:

> that's how I meant that the free Lisps have mostly worked to turn people
> away from Lisp. I didn't mean that you can't find free Lisps that people
> would have flocked to if they would only get over their prejudices. I
> meant that they don't, because of the many toys they have used and think
> are the norm. it seems, for instance, that in educational settings, Lisp
> and Scheme are not at all presented with anything resembling speed in mind,
> and so students who are used to C and C++ and ads reading "X compiles Java
> at over 10,000 lines per second", will have trouble _not_ remembering that
> speed was never discussed, that their compilers and interpreters were slow,
> etc, etc. I mean, we have people come in here and state that Lisp is an
> interpreted language at least once a week! it's an image problem, and it's
> a tragic element of that story that as Lisp implementers focus on other
> things, students and amateur programmers are turned into speed fanatics
> because that is the only forte of those other languages and systems. (and
> never mind that Allegro CL for Linux produces code that runs rings around
> C++ under Windows NT on the same machine. *sigh*)

I agree with all the above. ACL can effortless beat the sh*t out
of C++ even on a Windows platform, and it does it using far less
memory. Perhaps I'm being unfiar by comparing ACL for Windows with
VC++ and MFC, but C++ and MFC is a popular tool for developing
Windows code, so it seems like a reasonable comparison to me.
VC++ compiling MFC code demands more than 5 times as much RAM as
ACL, and still sucks in terms of compilation speed (ACL is fast
as lightning, while VC++ crawls), and ease of development.

All of which can translate into more development time for C++
than with Lisp. Why then am I not using Lisp to development
the code I'm paid for? Simply because I'm still saving up for
ACL for Windows, which costs about 8 times more than VC++,
which I got for _free_, as that's what I'm paid to use.

While the value of Lisp is obvious to me, this doesn't write
cheques. The money has to come first, then the tools, then the
code. Not that this is a real problem, as I can get by using
free tools (the ones with no strings attached), and then say,
"Hey, this works - in spite of not using C++ - and I _know_
I can do the same in Lisp, only better and faster."

I like Rainer's point about stats and numeric accuracy. I may
well use that argument to justify replacing our existing stats
code with something written in Lisp (or Haskell, which provides
similar numerical advantages as Lisp).

I recently took another look at a Lisp interpreter that I wrote
in the late 80s. I learned a lot from writing that, but I've
learned even more since then. Revising it so it could be compiled
with GNU C - for any platform that GNU C runs on - was a very
satisfying experience.

However, I'll probably need to do a lot more work before I make
it available on the Internet. It needs some docs, and a heavy
disclaimer about how and when I wrote it, i.e. to help me learn
more about Lisp. As a result, it's no speed demon.

Thanks for the thought-provoking posts!
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."


Reini Urban

unread,
Jan 27, 1997, 3:00:00 AM1/27/97
to

On Mon, 20 Jan 1997 11:19:30 +0100, jos...@lavielle.com (Rainer Joswig) wrote:
>Both Common Lisp and Scheme basics are relatively easy to learn.

In my eyes Common Lisp is quite hard to learn
(compared to standard lisp or scheme)
--
To prevent spam replies, my newsreader has misspelled my email address.
To send me email, remove the final "!". Sorry for the inconvenience!

Reini You can never surf too much!

Erik Naggum

unread,
Jan 27, 1997, 3:00:00 AM1/27/97
to

* Reini Urban

| In my eyes Common Lisp is quite hard to learn
| (compared to standard lisp or scheme)

what is "standard lisp"?

Martin Cracauer

unread,
Jan 27, 1997, 3:00:00 AM1/27/97
to

g...@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas) writes:

>In article <30631029...@naggum.no> Erik Naggum <er...@naggum.no> writes:

>| From: Erik Naggum <er...@naggum.no>
>| Date: 24 Jan 1997 13:56:07 +0000

>| that's how I meant that the free Lisps have mostly worked to turn people
>| away from Lisp. I didn't mean that you can't find free Lisps that people
>| would have flocked to if they would only get over their prejudices. I
>| meant that they don't, because of the many toys they have used and think
>| are the norm. it seems, for instance, that in educational settings, Lisp
>| and Scheme are not at all presented with anything resembling speed in mind,
>| and so students who are used to C and C++ and ads reading "X compiles Java
>| at over 10,000 lines per second", will have trouble _not_ remembering that
>| speed was never discussed, that their compilers and interpreters were slow,
>| etc, etc. I mean, we have people come in here and state that Lisp is an
>| interpreted language at least once a week! it's an image problem, and it's
>| a tragic element of that story that as Lisp implementers focus on other
>| things, students and amateur programmers are turned into speed fanatics
>| because that is the only forte of those other languages and systems. (and
>| never mind that Allegro CL for Linux produces code that runs rings around
>| C++ under Windows NT on the same machine. *sigh*)

>Actually, I think that the speed of the implementation, although


>important, is nowhere near as critical as other components.

While I think the rest of your posting is very valid, this statement
is not.

An existing performance problem in an implementation is usually a sign
for a misdesign. Several times I thought I should be clever enough to
work around such problems, only to find out that the implementors
aren't stupid either and the problem is a hard one.

I found myself quite often in a situation where a apparent minor
performance problems with a given language implementation (or OS, for
that matter) persisted and got worse and worse as a project continued.

I found CMUCL to be the only free CL implementation without major
performance showstoppers, and only when not taking PCL/CLOS into
account.

William D Clinger

unread,
Jan 27, 1997, 3:00:00 AM1/27/97
to will

The speed of a Lisp or Scheme implementation is tricky to
characterize, because an implementation may very well be
quite fast at some things but slow at others. For example,
I was the primary author of MacScheme, which was fast on tight
loops and generic arithmetic (especially fixnum arithmetic),
but was slow on non-tail calls. An implementor of Lisp or
Scheme has a lot more scope for both creativity and stupidity
than does an implementor of C, which tends to be implemented
approximately the same way by all compilers. See Dick Gabriel's
"Performance and Evaluation of Lisp Systems" for more on this.

I don't think it's useful to get too involved in a discussion
of which implementation is faster than another, because it
usually depends on precisely what you're trying to do and also
on your particular coding style. Having wasted a fair amount
of my life studying this sort of thing, however, I feel an urge
to offer some real albeit useless information.

Marco Antoniotti <mar...@crawdad.icsi.berkeley.edu> wrote:
> In the Scheme world, though I never tried it, I hear that the Stalin
> compiler could be a 1 or a 2 in my previous scale. AFAIK all the

> other Scheme's (apart from being incompatible from each other at some

> level) rank at 6 OR WORSE.

Chez Scheme and Larceny (our unreleased implementation) perform
in the same league with the commercial implementations of Common
Lisp that Antoniotti ranked as better than a 1. Stalin may be
in that league as well, but I haven't tried it. Gambit-C and
Bigloo would be a 1 or a 2; as noted below, their performance
is limited by the fact that they compile to C. MIT Scheme might
not be quite as fast, but it is probably on the order of 100 times
as fast as xlisp, which Antoniotti ranked at 6. I haven't used
Macintosh Common Lisp in recent years, but in 1988 its performance
(on the 68020) was roughly comparable to that of MacScheme, though
its performance profile was somewhat the opposite: MCL was faster
on non-tail calls, but slower on inner loops and arithmetic.

See http://www.ccs.neu.edu/home/will/Twobit/benchmarks1.html for
the kind of numbers that should not be taken very seriously, but
are better than hearsay. In particular these numbers illustrate
how the ranking of an implementation will vary depending on the
nature of the benchmark.

Michael Sperber wrote:
> Both Gambit and Bigloo can actually compete with C on at least some
> applications. I'd be suprised if, say, Chez Scheme, were
> significantly faster.

Chez Scheme is roughly twice as fast as Gambit-C on many programs,
mainly because Gambit-C compiles to C instead of to native code,
and you lose a factor of two because of the hoops that you have to
jump through to guarantee proper tail-recursion when generating
C code. This factor of two is acknowledged by Marc Feeley, the
author of Gambit. Bigloo also compiles to C, but may not suffer
quite as much because it doesn't try as hard to conform to the
IEEE/ANSI standard for Scheme.

William D Clinger

Jeff Barnett

unread,
Jan 27, 1997, 3:00:00 AM1/27/97
to

In article <30633807...@naggum.no>, Erik Naggum <er...@naggum.no> writes:
|> | In my eyes Common Lisp is quite hard to learn
|> | (compared to standard lisp or scheme)
|>
|> what is "standard lisp"?

In the current context, I guess it means an "uncommon Lisp".
So any lisp with a small distribution must be standard!

Jeff Barnett

PS It's been that kind of day.


Espen Vestre

unread,
Jan 28, 1997, 3:00:00 AM1/28/97
to

Erik Naggum <er...@naggum.no> writes:

> | In my eyes Common Lisp is quite hard to learn
> | (compared to standard lisp or scheme)
>
> what is "standard lisp"?

Standard Lisp was a pre common lisp attempt to standardize lisp.
There is a reference to The Standard Lisp Report in CLtL II.

--

Espen Vestre
Telenor Online AS

John Fitch

unread,
Jan 28, 1997, 3:00:00 AM1/28/97
to

Standard LISP is still very much alive. It is the basis of the REDUCE
algebra system the author of whom realised a need for a standard basis
for his programs way back in the 60s. The second Standard LISP report
was written in the late 1970s; I was responsible for the IBM370
implementation at that time.

But it still is active with CSL and PSL.

==John ffitch
Bath and Codemist Ltd

Rainer Joswig

unread,
Jan 28, 1997, 3:00:00 AM1/28/97
to

In article <30633807...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> * Reini Urban


> | In my eyes Common Lisp is quite hard to learn
> | (compared to standard lisp or scheme)
>
> what is "standard lisp"?

Maybe Standard Lisp? See http://www.rrz.uni-koeln.de/REDUCE/3.6/doc/sl/
for the Standard Lisp Report.

http://www.lavielle.com/~joswig/lisp.html

--
http://www.lavielle.com/~joswig/

Cyber Surfer

unread,
Jan 28, 1997, 3:00:00 AM1/28/97
to

In article <1997Jan26.1...@wavehh.hanse.de>
crac...@wavehh.hanse.de "Martin Cracauer" writes:

> In my opinion, people tend to rate Lisp as interpreted because they
> can't get the idea of a dynamic language that is compiled. They hear
> of Lisp features and automatically say "interpreted" where they may
> have thought "dynamic".

This is why I can answer almost any attack on Lisp from a C/C++
programmer by suggesting that they read PJ Brown's book. Some
people may have even forgotten that this stuff can be done even
in Basic. Yes, Basic was once interactive. I can't remember the
last time I read anything about a commercial Basic implementation
that was interactive. (Perhaps because today almost everything for
Windows is _batch_ oriented - ironic, eh?)



> In other words, the problem is not a bad image of Lisp, but the fact
> that people are ignorant and tend to fail to recognize what
> performance problems are really involved with a dynamic language.

This is why I so often find myself recommending Brown's book.
Too many people don't have any idea what "interactive" means!
You're right, they think it means "interpreted". Even worse,
they think that "compiled" always means "native code compiled".

Erik sometimes calls people stupid, but if he's right, then we're
in a hopeless situation. If you're right, and I think you are, then
it's a case of ignorance, and we can fix that. It'll take a lot
of effort and time, but it can be done.

Perhaps Java is helping to make this possible, but it might also
make things much worse if it fails. After all, the JVM is seen as
"interpreted", which it isn't. Implementations may, but they also
may be compiled to native code. Not enough people realise this,
and this may be another ignorance problem.

If Java can suffer in this case, think about what ignorance can
do to Lisp, which is much harder for the average C hacker to
understand. It's going to be hard work.

Rainer Joswig

unread,
Jan 28, 1997, 3:00:00 AM1/28/97
to

> On Mon, 20 Jan 1997 11:19:30 +0100, jos...@lavielle.com (Rainer Joswig) wrote:
> >Both Common Lisp and Scheme basics are relatively easy to learn.
>

> In my eyes Common Lisp is quite hard to learn
> (compared to standard lisp or scheme)

Really?

Perhaps some people try to tell you about CL which doesn't understand
it themselves (because they don't use it for example).
Then some people try to tell you that CL lacks pattern matching
like some other functional language. Not only is it easy
to integrate pattern matching, but they don't understand,
that for larger software libraries pattern based invocation
is not very maintainable. Then people begin to tell you
that CL does not allow to return "tuples" of values.
Again this is easy (use VALUES, or structures, whatever).

Common Lisp is releatively easy to understand. Not
full Common Lisp - you don't need to tell them about
DEFSETF or about meta classes. But Common Lisp
has the same basic properties like Scheme.
It additionally has values and function cells and
supports also dynamic binding (aka FLUID-LET in Scheme).
Well, that is no big deal. Then Common Lisp has a
small set of special forms, some macros and functions.
The basic evaluation model is easy.

Then you start programming. You will need some library
functions. Well, Common Lisp has a lots of stuff
in the language. You want to print something -
use PRINC (or whatever). Its already there. If you
need something complicated - its there, too.

You just need an overview over the CL libraries. In case
you need something - just look into the manual.
Why should it be more difficult to program
a student project for searching a maze and
printing the results to ASCII text in Common Lisp,
then in Scheme? All you need of CL looks
similar to the Scheme stuff.

I don't get it. I always thought, that CL is really
easy to master (compared to, say, Haskell or C++).

Rainer Joswig

--
http://www.lavielle.com/~joswig/

Cyber Surfer

unread,
Jan 28, 1997, 3:00:00 AM1/28/97