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

what is "standard lisp"?

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

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.

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.

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.

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

Jeff Barnett

--

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.

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

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

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.

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

In article <joswig-ya023180002801971347360...@news.lavielle.com>
           jos...@lavielle.com "Rainer Joswig" writes:

Perhaps some people prefer the functional syntax, using
tuples. That doesn't necessarily imply that a tuple object
is CONstructed. It might be, but I think that's a detail
of the implementation, not the language.

It looks like you're defending CL by attacking another style
of programming. I hope this not the case, as I don't believe
that it's necessary. No language is so good that it justifies
such an attack, and I'm know that you can find better ways
of defending CL.

So, I'm assuming that you just badly phrased your point,
by appearing to include some language politics.

Mastering any language worth learning takes time. After
more than 10 years, I'm still learning CL. I'm also still
learning C++, tho I feel I've used it enough by now.
I haven't _begun_ to master Scheme!

I can see that CL is very *large* & therefore intimidating compared to
Scheme, but that can be fixed by teaching it the right way.  Scope &
extent people find hard, but is common between them.  Different fn and
variable namespaces make CL harder I think. call/cc makes scheme very
much conceptually harder though for many people.

So it would be quite interesting to know why CL is harder (or why
scheme is harder) and how that could be fixed, if it can.

William D Clinger <w...@ccs.neu.edu> wrote:

Gambit-C is about the same performance as Chez-Scheme (when Gambit-C
uses "block" compilation to unsafe code with fixnum/flonum specific
arithmetic).  Of course run time performance is only one part of the
story since many other characteristics are important to compare as
well in a practical setting (compile time, portability,
interoperability, adherence to the standards, language extensions,
debugging, etc, etc).

IMHO, CL looks like it is much harder to master the Scheme.  The
following
is my rebuttal.

Why would I want (or need) pattern matching in Lisp?  Is this like
pattern matching in ML?  Can you use CL and avoid using patterns?

Tuples?  Values?  Structures?  If I want to return more than value,
I return them in a list (or vector).  Why would I want tuples?  
Are structures like structures in C?  How are tuples different from
structures and lists?  Are values a new data type in CL?

While scheme has essentially "define,"  Common Lisp has several
"DEFsomethings".
Why does Common Lisp have some many definitions?

If you need to understand "meta classes" to master CL, this is also
one strike against CL.

Why do you need meta classes in Common Lisp?

Scheme's printing options are much clearer to me.  You apply the
print function to the value and it prints it.

CL has really exotic print functions with lots of flags and options.
It reminds me of C's print function.  There are more details.

I bet CL is really easy to master, when compared to C++.

However, IMHO, it is hard to defend that CL is easier to
master than Scheme.  Just compare the reference manual size.

In CL defense, one could argue that CL has other advantages over
Scheme.  I bet it is easy print out a number in hexidecimal format.

In article <32F06A73.5...@widomaker.com>,
Earl & Daniella Harris  <eshar...@widomaker.com> wrote:

* Earl Esharris Daniella Harris
| IMHO, CL looks like it is much harder to master the Scheme.

FWIW, I found the opposite to be true.  my favorite example is `member',
which Common Lisp calls `member', but which Scheme calls `memq', `memv', or
`member' according to which function should do the testing.  in Common
Lisp, I can choose the test function with :test, and use `eq', `eql' or
`equal' as I see fit.  should I want a different function, such as
`string-equal', I can use that, too.  in Scheme, I must implement my own
`member' with `string-equal' as the predicate.  in practice, I implement a
new `member' (which must be called something other than `member' since
Scheme doesn't have packages and redefining isn't kosher), which takes a
function as argument.  in like manner, I must reimplement everything else I
need with a higher level of abstraction than Scheme provides.  I have
concluded that Scheme is a pretty dumb language as standardized.  had all
of this hype about functions as first-class arguments been true, wouldn't
Scheme have used them more often, I wonder.

| If you need to understand pattern matching to master CL, this is one
| strike against CL.  Scheme doesn't have this; it isn't necessary.

you don't need to.

| If you need to understand tuples and structures to master CL, this is one
| strike against CL.

you don't need to.

| Are values a new data type in CL?

no, all functions return multiple values in Common Lisp.

| If you have to learn and differentiate between several DEFs, this is a
| strike against CL.

you need to know only `defvar' and `defun' to get going.

| While scheme has essentially "define," Common Lisp has several
| "DEFsomethings".  Why does Common Lisp have some many definitions?

(1) because Common Lisp recognizes that a single namespace for functions
and variables is bad for you.  (2) because Common Lisp has features that
Scheme does not have.

`defsetf' was mentioned.  in Common Lisp, if you have a function (foo x)
that returns some piece of information, the typical function to make that
function return some new value known by your program is (setf (foo x)
new-value).  e.g., if you retrieve elements from an array with (aref A i),
you store a new value with (setf (aref A i) x).  in Scheme, you use
specialized functions to access different kinds of arrays, and you must use
different functions to store values into them, too.  you define your own
setf methods (or "setter functions") with defsetf.  you can also define
them with (defun (setf foo) ...) just like other functions.  I find this
very elegant, and certainly much more so than functions named `set-foo!'.

| If you need to understand "meta classes" to master CL, this is also one
| strike against CL.

sigh.  you don't need to.

| If you need to understand several flags and options in the print
| functions, this is one strike against CL.

sigh.  you don't need to.

| Regarding the evaluation model, CL's doesn't treat functions as first
| class objects.  I can't pass functions around like other values (numbers,
| lists, etc).

you should have asked a question.  the above is as untrue as you can get.
however, functions aren't normally values of variables.  this is seldom as
useful as Schemers think it is.  the only difference between Scheme and
Common Lisp regarding functions is that in Scheme the first element of an
expression is evaluated like the rest of the elements, whereas in Common
Lisp, it is evaluated specially.  evaluating a function call form in Scheme
means (apply #'funcall (mapcar #'eval form)), except that Scheme is allowed
to evaluate arguments in any order, whereas in Common Lisp it means
(apply (car form) (mapcar #'eval (cdr form))), keeping with Common Lisp
syntax in both cases for the sake of comparison.

| However, IMHO, it is hard to defend that CL is easier to master than
| Scheme.  Just compare the reference manual size.

Scheme is a relatively low-level Lisp.  you _can_ build tall abstractions,
but you run into many serious problems in scaling, not to mention the fact
that Scheme is a language of bare necessities, like living in a cave, while
Common Lisp is a language of complex societies where all the infrastructure
you want to take for granted is indeed already implemented.

however, I can sympathize with you on the cognitive level.  Common Lisp
seems large and unwieldy.  let me illustrate with an anecdote.  I moved to
California to work on a project and stayed for five months.  when I first
got there, I found that I experienced cognitive overload in supermarkets.
this was the first time I had had to buy my own groceries in the U.S. and
was not at all used to the variety or the brand names or anything.  there
were dozens of different maple syrups, a hundred kinds of bread, etc.  back
home in Oslo, there is much less variety, and some stores even specialize
in having a small number of products, like 800.  gradually, over many
years, I had come to choose around 40 different products that I bought on a
regular basis.  I could shop sleeping.  however, in California, my nearest
supermarket was quite small by U.S. standars, and offered only 3000 or so
different products, none of which even looked like what I was used to.  it
dawned on me after having become quite tired of the first couple shopping
experiences that I had tried to take in all of them at the same time, that
I had no grounds for comparisons, and that I still didn't think in dollars
so I didn't even have a working economic model to fit things into.  in
response to this cognitive overload, I systematically went through a small,
new section of the store every time I went there, after I had found a
subset of their products that I could eat.  it still took two months before
I had a working knowledge of brand names, product categories, price levels,
etc.  however, my point is that although I recognized a problem in my
approach to something new and very large by my standards, I didn't starve
while I tried to sort out which maple syrup to pour on which breakfast
waffles with which fruits on it.  (I learned later that I had skipped the
best maple syrup, too.)  when I got home, I had acquired a taste for the
variety, and found myself buying at least 5 times more kinds of goods on a
regular basis than I used to.  if you like, Scheme is like a bakery that
produce three kinds of bread according to clearly specified nutritional
models, while Common Lisp is like a supermarket with baked goods from a
large variety of bakeries.  once you enjoy the variety, you won't find the
bakery confined to "only what's good for you" to be much of a treat.

it may be worth noting that I had already become really annoyed by C's and
Unix' lack of useful functions and all the manual work that was necessary
to get even simple things done.  (such as: in a system-wide shell init
file, you need to set the search list (path) for interactive shells.  it is
important that a few directories be present for all users, but their order
is immaterial and may be chosen by the user.  if some directory is not
present in the search list, it should be made the new first element of the
sublist that contains only elements from the required list, in other words:
it should be added before any other required directories, but after any
that the user might have set up.  exercise: do this in the various shells,
in Scheme, and in Common Lisp.  for extra bonus points, do it in perl.)

Here's another stick on the fire:

On a SPARCStation an Allegro CL uses *11 meg* to print "hello, world".
                     SCM uses *1 meg* to print "hello, world".

CL requires more $$ for ram and disk.

1) Some concepts were quite hard to get for me, scoping, multiple
namespaces, reader macros (understanding existing programs is a lot
easier when you got the idea that all these #-constructs are just the
same as calling an S-expression macro) and in some ways
setf-constructs.

2) I learn best by reading existing sources. In Common Lisp, you will
face the whole range of teh language.

On the other hand, while it was hard to read such programs, it was
very useful. For example, when a sensible programmer chooses the best
sequence type for a given task. In Common Lisp, he will most likely
use constructs that you can look up in CLtL2. In C++ before STL, he
usually will implement his own stuff or use a non-standard lib and in
C people are very likely to push everyting into arrays.

3) While I liked the syntax, I found it to be pretty uncomfortable
when it comes to access sequence members and struct entries and
instance variables.

Also, the syntax for declarations is not really intuitive.

4) It is not easy to get decent performance out of Common Lisp when
you don't have an idea what makes a hashtable different from a
non-hashing assosication table and why people invented lists and why
it is useful to keep an pointer to the end of a list.

Of course, you will not write good peforming C programs also, but in C
you are likely to use arrays of inlined data members, which was for my
applications fast enough. In Common Lisp, you might end up using lists
like arrays and get no compile-time typechecking at all.

5) Usually no source-level debugging. I found it very useful to see a C
program step-by-step with variable watches turned on.

6) Profiling requires you to set up the symbols you want traced in
advance. With GNU gprof for C, you just say "profile this program" and
it uses all functions it has an entry for.

7) Environment issues. It takes some time to get used to work in a
permanent image. For example, why can't you load a package that
contains a symbol you just tried to access? Because you just triggered
the symbol to be created in the current package. Not easy to get for a
batch-language user.

I don't think Scheme is much easier to learn. C is at least easier to
understand for someone who has an understanding how a CPU works and
how data is arranged in a computer (which was the case for me).

I don't want to start a language flame war, also. After all, this is a
description of a past state of mine and you're not going to change
history, no matter how wrong I was :-)

Earl & Daniella Harris (eshar...@widomaker.com) wrote:

[Snip]

: Ok.  I don't understand CL.  When I tried to teach myself CL, I was
: expecting a simple language like Scheme.  The details of CL seemed
: overwhelming.  I kept asking myself, why is this SO complicated?
: This is suppose to be Lisp?

It's so complicated because it's so powerful.  There's so much
that you can do in Common Lisp that there are naturally many
things to learn.  Note however that you can put off learning
many of these things and still write effective programs.
A testament to this fact is that many of Common Lisps'
capabilities can be (or may even be) written in Common Lisp
itself, using a few core primitives.

: IMHO, CL looks like it is much harder to master the Scheme.  The
: following
: is my rebuttal.

Again it's harder to master, but then that's because there is
more to master.  That's like saying "Chess is Harder to
Master than Checkers".  Well sure it is, but that's not
a disadvantage of chess!

: > 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

: If you need to understand pattern matching to master CL, this is one
: strike
: against CL.  Scheme doesn't have this; it isn't necessary.

Common Lisp doesn't offer pattern matching.  Maybe you should
actually try to learn it or look at it in detail before reaching
such hasty conclusions.

: Why would I want (or need) pattern matching in Lisp?  Is this like
: pattern matching in ML?  Can you use CL and avoid using patterns?

Scheme is basically a tiny version of Common Lisp (this may be a bit
of an oversimplification), so that alone should give you an
idea of what Common Lisp can and can't do.

: > 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).

: If you need to understand tuples and structures to master CL, this is
: one strike against CL.

Mastery of any language means that you should know the ins and outs
of that language.  Contrast this with being able to effectively
use a language.  With Common Lisp you can effectively use the
language without understanding structures (I don't even know
if tuples are supported).  You can use lists instead of
structures and use them instead.  

Structures however are very simple to use, and very well designed,
and they are there for when you are ready for them.

: Scheme doesn't have tuples; it isn't necessary.  Some scheme
: implementations
: have structures, but you don't need to learn it.

I don't think that Common Lisp even has tuples either, and you
don't have to learn structures in Common Lisp.  Again you've
got lists, just use them.

: Tuples?  Values?  Structures?  If I want to return more than value,
: I return them in a list (or vector).  Why would I want tuples?  

You could do the same in Common Lisp.  

: Are structures like structures in C?  How are tuples different from
: structures and lists?  Are values a new data type in CL?

I can't speak for tuples, and I'm not sure what you mean by
"values", but I can tell you how the structures in Lisp work.

Basically you define a structure (much like you would in C), but
instead of using a "." to access structure fields, Lisp creates
specialized functions -- accessor functions for you to access
the structure fields with.  This hides the implementation details
and makes it a snap for you to later replace them with another
implementation (if you so desire).  Structures in Lisp are
basically ADTs (abstract data types), and so they are like structures
in other languages in that you access particular fields and can
refer to them as a whole, but are different in that they
are abstracted.

: >
: > 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.

: If you have to learn and differentiate between several DEFs, this is
: a strike against CL.

Again you can do a lot (possibly more than Scheme) without
differentiating between several DEFs.  Again, think of Scheme
as a tiny subset of Common Lisp.  With Common Lisp, you can
choose to use a tiny subset, and so it can be very much like
Scheme (in terms of simplicity).  No one is forcing you to
use all these features, but they are there for when you
need them.

: While scheme has essentially "define,"  Common Lisp has several
: "DEFsomethings".
: Why does Common Lisp have some many definitions?

Because they do different things.  Again you are not forced
to use all these definitions.  

: If you need to understand "meta classes" to master CL, this is also
: one strike against CL.

The same answers apply, let's just fast forward since this is
redundant.

[Snip]

: Scheme's printing options are much clearer to me.  You apply the
: print function to the value and it prints it.

: CL has really exotic print functions with lots of flags and options.
: It reminds me of C's print function.  There are more details.

Again use what subset makes you feel comfortable.  Scheme is simpler
because it's *WEAKER*.  Get it?

[Snip]

: I'm not sure a libary makes a language easier to master.
: A libary can be a convenience to the programmer.  It saves
: me the trouble of writing some programs.

Think of much of Common Lisp as optional libraries for you
to use when you decide you need them.

[Snip]

: Regarding the evaluation model, CL's doesn't treat
: functions as first class objects.  I can't pass functions
: around like other values (numbers, lists, etc).

Yes you can.  The thing is with Common Lisp (as contrasted
with Haskell), you'll need a special quoting notation
to keep things clear, but that's it.  

That's how functions like funcall and apply work, by
taking functions as arguments.  If you couldn't do that
in Common Lisp then how do these functions even exist?

: I bet CL is really easy to master, when compared to C++.

: However, IMHO, it is hard to defend that CL is easier to
: master than Scheme.  Just compare the reference manual size.

I'm not arguing that CL is harder to master than Scheme, I'm
merely trying to point out that mastery is one thing, and
using something productively is another, and you can use
CL productively without all that much effort.

: In CL defense, one could argue that CL has other advantages over
: Scheme.  I bet it is easy print out a number in hexidecimal format.

That was uncalled for.  Common Lisp is vastly more powerful than
Scheme and is therefore larger.  It's that simple.  If you can't
come to grips with this simple fact, then maybe Common Lisp
really is beyond you and you should stick with something simpler
like Scheme.  

[Snip]

: Earl Harris Jr.

--
Cya,
Ahmed

In article <854545474...@wildcard.demon.co.uk>,

But some people have been
struggling with similar approaches years ago. Its
a bit like what people experienced with rule based
languages in real world software (like OPS5-based
configuration systems, or even the infamous sendmail).

I'm not saying anything bad about Haskell, it´s just that
even with FP knowledge it is not easy to master and some
books (there is a nice German one) about Haskell do look
like white noise to the uninitiated.

Rainer Joswig

On 30 Jan 1997 20:15:48 +0000, Erik Naggum <e...@naggum.no> wrote:

Some misconceptions about Scheme from the view of CL programmers need
clarification.

In Scheme, equal? works on strings.  No need to.

Erik> in practice, I implement a new `member' (which must be called
Erik> something other than `member' since Scheme doesn't have packages
Erik> and redefining isn't kosher), which takes a function as
Erik> argument.

Redefining *is* kosher in Scheme as of the IEEE standard.

Erik>  in like manner, I must reimplement everything else I
Erik> need with a higher level of abstraction than Scheme provides.

At least that is easy in Scheme.  In Common Lisp, if I want call/cc
(and it is *much* more useful than Common Lisp programmers usually
care to acknowledge), I cannot express it in terms of other Common
Lisp primitives.

The high-level macro system that Scheme has (about to be made a
mandatory feature for R5RS) (or something with equivalent
functionality) is very hard to implement right in Common Lisp.  I
doubt that it's been done.  (Except maybe as part of PseudoScheme :-})
I'd be happy to be educated on the subject.

Erik> (1) because Common Lisp recognizes that a single namespace for functions
Erik> and variables is bad for you.

Again, that's an assertion without any proof.  Multiple namespaces
greatly complicate dealing with names conceptually, especially when
the same name has multiple bindings with disjoint meanings.  Possibly
a matter of taste, admittedly.

Erik> (2) because Common Lisp has features that Scheme does not have.

So?  Scheme has features that Common Lisp does not have.

Erik> `defsetf' was mentioned.

defsetf is trivial to define with Scheme high-level macros.

Erik> you should have asked a question.  the above is as untrue as you can get.
Erik> however, functions aren't normally values of variables.  this is seldom as
Erik> useful as Schemers think it is.

Erik, you should have asked a question.  It is immensely useful all
the time.  I'd be happy to send to oodles of source code where having
to use funcall would greatly screw up the code.  Admittedly, code that
CL programmers would

Erik> Scheme is a relatively low-level Lisp.  you _can_ build tall abstractions,
Erik> but you run into many serious problems in scaling,

Such as?

Erik> not to mention the fact that Scheme is a language of bare
Erik> necessities, like living in a cave, while Common Lisp is a
Erik> language of complex societies where all the infrastructure you
Erik> want to take for granted is indeed already implemented.

* Matthew R. Wette
| On a SPARCStation an Allegro CL uses *11 meg* to print "hello, world".
|                      SCM uses *1 meg* to print "hello, world".

this is very odd.  ACL 4.3 on my SPARCstation has a swap footprint close to
5M.  CMUCL has a swap footprint of about 1M.  scsh uses 9M, and MIT Scheme
eats 12M.

| CL requires more $$ for ram and disk.

some Scheme _implementations_ require far more RAM and disk than some
Common Lisp _implementations_, and vice versa, I'm sure.

* Michael Sperber
| Some misconceptions about Scheme from the view of CL programmers need
| clarification.

that may be, but please do not add more of them.

| >>>>> "Erik" == Erik Naggum <e...@naggum.no> writes:
|
| Erik> in Scheme, I must implement my own `member' with `string-equal'
| Erik> as the predicate.
|
| In Scheme, equal? works on strings.  No need to.

`equal' is case sensitive.  `string-equal' is not.  `equal?' in Scheme is
also case sensitive.  if this is not sufficient, choose a different
function, and get the point.

| Erik>  in like manner, I must reimplement everything else I
| Erik> need with a higher level of abstraction than Scheme provides.
|
| At least that is easy in Scheme.

sigh.  it may be hard, it may be easy.  in Common Lisp I don't have to.

| Erik> (1) because Common Lisp recognizes that a single namespace for functions
| Erik> and variables is bad for you.
|
| Again, that's an assertion without any proof.  Multiple namespaces
| greatly complicate dealing with names conceptually, especially when
| the same name has multiple bindings with disjoint meanings.  Possibly
| a matter of taste, admittedly.

where was the first "assertion without proof"?  your own?

| Erik> `defsetf' was mentioned.
|
| defsetf is trivial to define with Scheme high-level macros.

again, you need to roll your own.  all those "trivial" things add up.

| Erik> however, functions aren't normally values of variables.  this is
| Erik> seldom as useful as Schemers think it is.
|
| Erik, you should have asked a question.  It is immensely useful all the
| time.

because in Scheme, you have no other choice.  if you need it in Common
Lisp, you've implemented a different evaluation model before all those
trivial issues in Scheme have been implemented.

| I'd be happy to send to oodles of source code where having to use funcall
| would greatly screw up the code.

"greatly screw up the code"?  misconceptions, eh?  you're marketing.

| Erik> Scheme is a relatively low-level Lisp.  you _can_ build tall
| Erik> abstractions, but you run into many serious problems in scaling,
|
| Such as?

lack of a standard package system, for starters.

| Erik> not to mention the fact that Scheme is a language of bare
| Erik> necessities, like living in a cave, while Common Lisp is a
| Erik> language of complex societies where all the infrastructure you
| Erik> want to take for granted is indeed already implemented.
|
| As far as infrastructure for building abstractions is concerned, I
| want (and need) call/cc and macros.  So?

as if Common Lisp didn't have macros.  sheesh!

call-with-current-continuation is unique to Scheme.  somehow, people can
actually get work done in other languages.  listening to Schemers, I wonder
how this is at all possible without call-with-current-continuation.  could
it be that Scheme has removed all the _other_ mechanisms and replaced them
with a single very complex idea that is then used to reimplement them all?

in Scheme, you have to implement a lot of minor stuff.  this creates one
Scheme environment per user or group of users.  such is indeed the case.
in Common Lisp, it's there.

Still ...

Erik> | Erik> (1) because Common Lisp recognizes that a single namespace for functions
Erik> | Erik> and variables is bad for you.
Erik> |
Erik> | Again, that's an assertion without any proof.  Multiple namespaces
Erik> | greatly complicate dealing with names conceptually, especially when
Erik> | the same name has multiple bindings with disjoint meanings.  Possibly
Erik> | a matter of taste, admittedly.

Erik> where was the first "assertion without proof"?  your own?

The assertion was "a single namespace for functions and variables is
bad for you", to quote you.  Yours.  No proof.

Erik> lack of a standard package system, for starters.

Admitted, but also possible to build yourself.  The code is out there
Erik, just download it.  Of course, all these "little things add up."
A matter of taste if you'd rather be able to choose which ones and how
they work, and then grab them, or if Common Lisp pushes all this stuff
at you.  For some programmers (me, for instance), Common Lisp rarely
provides the right abstractions, but rather something which is only
almost right.  For others, it may be perfect.

This seems to be the difference in design philosophies between Scheme
and CL.  Language elements make it into Scheme only on unanimous
consent of the RnRS authors, pretty good evidence that they are "The
Right Thing".

Read Dick Gabriel's paper on Common Lisp for some evidence on why.
I'm not trying to argue that Scheme is "better" than CL (which Erik is
trying to push at me), I'm just saying that people exist who prefer
Scheme to CL.  (And that they, too, are getting serious work done in
Scheme.)

Erik> | As far as infrastructure for building abstractions is concerned, I
Erik> | want (and need) call/cc and macros.  So?

Erik> as if Common Lisp didn't have macros.  sheesh!

CL's macro system is by far not as convenient and (worse) far more
unsafe than Scheme macros.

Erik> call-with-current-continuation is unique to Scheme.  somehow, people can
Erik> actually get work done in other languages.

Certain things you can't do without call/cc (or some equivalent
mechanism such as shift/reset), such as building mechanisms for
coroutines, threads etc.  With call/cc, however, you can build *any*
control structure.

Erik> listening to Schemers, I wonder how this is at all possible
Erik> without call-with-current-continuation.

I've never seen anybody claim that.  Quote someone, Erik, just once!

Erik> could it be that Scheme has removed all the _other_ mechanisms
Erik> and replaced them with a single very complex idea that is then
Erik> used to reimplement them all?

Common Lisp's idea of non-local control transfer is at least as
complex as call/cc, but nevertheless not as powerful.  The formal
semantics in the Scheme standard takes up 12 4-inch lines, none of
which has more than 2 inches of stuff on it.  Two of those lines are
declaration lines, two are error messages, which leaves 8 operational
lines.  Those lines would easily fit on one or two lines on a full
page.  How long is the explanation of non-local jumps in CL?

Erik> in Scheme, you have to implement a lot of minor stuff.  this creates one
Erik> Scheme environment per user or group of users.  such is indeed the case.
Erik> in Common Lisp, it's there.

True.  Is this a bad thing for Scheme?