I know Scheme is a dialect of Lisp. But I want know exactly the point(s)
that distinguish(es) both from each other! It is tough for a newbie in this
field to get a clear image without profound experiences. Any clue will be
highly appreciated.

Here are some things I think are key differences between Lisp and Scheme:

 (1) They have different goals.

     Scheme values aesthetics over virtually all else.
     Common Lisp places aesthetics low on the totem pole.

     Scheme values small size-of-language and ease-of-language-implementation.
     Common Lisp assumes that it's ok for the base language to be large and
     to take a while to implement, and that it's small size-of-program
     and ease-of-program-implementation that matters.

     Scheme abhors redundancy of expression, so tends not to offer more than
     one way to do a particular thing.
     Common Lisp assumes it serves a varied community with a variety of
     programming styles and provides numerous options to allow the coresidence
     of people with varied tastes.

     Scheme doesn't focus on implementation compatibility, and has
     historically virtually ignored "small differences" that might make
     for porting problems.
     Common Lisp focuses a great deal on language portability, specifying
     numerous ways of detecting subtle differences between implementation
     for ported programs trying to "get a foothold".

 (2) They are specified differently.

     Scheme has both an English text description of its semantics and
     a formal semantics.
     CL is specified in English text only.

 (3) They have several highly visible differenes in the core language.

     Scheme has call-with-current-continuation.  Common Lisp does not.
     UNWIND-PROTECT enjoys a clear semantics in Common Lisp but is beyond
     the scope of the language in Scheme, at least partly becuase its
     semantics would be problematic in Scheme in the presence of
     call-with-current-continuation (and the first class continuations
     resulting from it).

     Order of argument evaluation in Scheme is generally unspecified,
     whereas it is specified in Common Lisp.

     Scheme function argument notations provide primitively only for
     "required" and "rest" arguments.  There is no provision for individual
     "optional" arguments, nor for "keyword" arguments, both provided by
     Common Lisp.

     Scheme has mandatory tail call elimination.  Common Lisp does not.

     Common Lisp separates programming units by "package" and Scheme by
     "module".  Though these are often contrasted as if they attempt to
     solve the same problem, the two are in fact orthogonal.  CL could have
     a module system, but chooses not to.  Scheme could have a package system
     but chooses not to.  Package systems separate references at the data
     level, independent of attached semantics.  For example, the program
       (eq 'x:foo 'y:foo)
     illustrates a use of symbols that are not variables in a way that
     exploits the package system.

     Scheme is a "Lisp1" (single variable namespace); Common Lisp has
     several namespaces, though is commonly called merely a "Lisp2" because
     of the focus on separation of function cells and value cells; in fact,
     Common Lisp also has separated namespaces for block tags and go tags.
     A consequence of the distinction in namespaces is the presence of
     (FUNCALL f ...) and (FUNCTION f) notations in Common Lisp, which are
     not present in Scheme.  Another consequence of this is the need for a
     much more complicated macro system in Scheme, using macro hygiene to
     avoid problems that would otherwise be introduced by name clashes;
     largely these problems do not occur in Common Lisp because of the
     combined presence of its multiple namespaces and its package system,
     so a macro hygiene system, while it would be possible in CL is not
     in practice needed.  Some also find the Scheme macro system elegant,
     although most admit it is less computationally powerful than the
     Common Lisp macro system.

     A class system and condition system are well-integrated with Common
     Lisp, and are largely absent in Scheme.

Frank Que

"Kent M Pitman" <pit...@world.std.com> wrote in message
news:sfwlmtympa2.fsf@world.std.com...

I know in particular at MIT when I was there (which is now 20 years ago),
there was an explicit goal of NOT teaching any programming language but
merely assuming you knew them or could learn them as needed.  The idea
was, again, to teach concepts not details.  I think the design of Scheme
and Structure and Interpetation of Computer Programs (S&ICP, the common
teaching text) reflect this.

Note well that some implementations of Scheme are as detailed and
commercial oriented as CL.  However, I would personally say that this
is due more to the individual commitment of the implementor than the
language; I would almost go so far as to say these implementations
succeed in spite of the basic spartan design of Scheme, rather than
due to it.  Of course, the Scheme designers will claim that it follows
from their spartan design that such good implementations arise, but I
doubt that is really true.  Nothing about the Scheme spec especially
suports a vendor in the creation of an efficient implementation.  And,
if I remember right, Steele at some point early on wrote a compiler
for Scheme called "Cheapy", which turned out to produce code that ran
slower compiled than interpreted... something that we might naively
think of as "not possible" until we think about it, but that is in
fact not a property of the universe, so much as a property of which
product results people are willing to actually show their friends...

I don't mind that people teach people the relation between recursion and
iteration, but I do mind a LOT that they try to untrain them to think in
terms of standard iteration constructs and to think such things are dirty
in some way that tail recursion is blessed not to be.  College courses should
teach "alternatives", not "dogma".  And the Scheme community is, for whatever
reason, rich with dogma.

In one way, it saddens me that CL doesn't require the optimization because
I'd really like people to be able to use it when they can.

  The Lisp that Scheme is a "dialect" of is akin to the Indo-European
  that both English and Swahili could be described as "dialects" of.
  These "dialects" have diverged so much it is now useless to think of
  the Lisp of which Scheme was supposedly a dialect as something that
  still exists.  The Lisp community continued to evolve after Scheme
  split off to go their own way.  Scheme is in my view much closer to a
  dialect of Algol with some Lisp heritage.

  Hence the last sentence, as in "dialect of Algol".

I recently had the dubious pleasure of editing another scientist's Lisp code
and porting it to a more modern dialect of Lisp. His penchant for using
globals containing local state information makes it almost impossible to
reproduce simply because it is difficult to track which functions step on
these shared variables across the two-dozen or so modules of Lisp. Yechh!

Please, let's stop teaching Fortran as a first and only language, and start
passing along a little more abstract reasoning, like functional closures,
recursion, immutable global data, and so forth. Most scientists feel that
they don't need to learn anything more about programming than what they
learned as college freshmen. I find that a lot of Pysiciains and Attorneys
also think this way. Hey, after all they got their Doctorates in whatever,
what more is there worth learning?

 Lieven> For some value of Indo-European. Swahili is a Niger-Congo language
 Lieven> that noone I'm familiar with has ever claimed any relationship to
 Lieven> Indo-European for.

 (loop for entry in some-list
       for name = (person-name entry)
       for age  = (person-age  entry)
       collect (list name age))

You can express this and many other things in terms of tail recursion,
but I don't personally see the value of doing so.  Even so, my point is that
students should be taught that this kind of breakdown is just as acceptable
as tail recursion.  I do so tire of having to de-program Scheme converts
from believing that only the Scheme-style

  (let loop ((input list) (output '()))
    (if (null? input) (reverse! output)
        (let ((entry (first input)))
          (let ((name (person-name entry))
                (age  (person-age  entry)))
            (loop (cdr input) (cons (list name age) output))))))

is acceptably clear.  Among other things, this contains a lot of verbiage
which is subprimitive to what's being accomplished, such as the need
to maintain an extra loop variable for the list being traversed, and another
for the result being accumulated, not to mention the programmer having to
know the stupid trick about consing up a list backward and then reversing it,
which though good "world knowledge" for a programmer to have really isn't
relevant to the domain task at hand.  And, of course, Common Lisp doesn't
have tail recursion elimination, so to avoid possible stack overflow in the
case of long lists, the Scheme loop above would have to at least be rewritten
using DO (which is effectively a sugaring of a tail recursive loop). But
LOOP hides these "implementation level" extra variables, the knowledge of
accumulation tricks, and certain potential "stack" issues and other traversal
strategy issues in a way that I have over time come to agree with LOOP
proponents is expressionally important.

  Some Common Lisp environments come with a cross referencing facility
  that allows you to query the system for all such references, such as
  Allegro CL from Franz Inc.  It doesn't take the pain of dealing with
  such code away, but you can at least retain control over it.

   (loop for ...
      collect ..)

or wrapped in a macro such as my COLLECING / WITH-COLLECTORS things
(http://www.tfeb.org/lisp/hax.html#COLLECTING) which are probably
pretty typical of what people do.

  Only one extra cons, actually.

(do* ((tail (cons nil nil) (cdr tail))
      (head (cdr tail))
      (list <list> (cdr list))
      element)
    ((null list) head)
  (setf element (car list))
  ...
  (setf (cdr tail) (list element)))

| Nobody seems to use it though and it isn't even mentioned in textbooks
| anymore.

  Well, it has naturally become macrofied because it _is_ quite hairy
  and intrusive to write manually every time.  Software patterns
  notwithstanding, some things are just better off being macros.

| I think I saw it in an old book by Wilensky or Touretzky?

  I have only seen it explained.  The coding seems to vary according to
  the specific needs of the body of the loop.

Kent M Pitman <pit...@world.std.com> writes:

Harvey and Wright's textbook Simply Scheme makes this point.
They introduce higher-order functions before recursion.

--

Jonathan Jacky                          j...@radonc.washington.edu
Radiation Oncology, Box 356043          voice:  (206)-598-4117
University of Washington                FAX:    (206)-598-6218  
Seattle, Washington  98195-6043 USA

These are not the goals of Common Lisp.

Kent>  (loop for entry in some-list
Kent>        for name = (person-name entry)
Kent>        for age = (person-age entry)
Kent>      collect (list name age))

Kent> You can express this and many other things in terms of tail
Kent> recursion, but I don't personally see the value of doing so.
Kent> Even so, my point is that students should be taught that this
Kent> kind of breakdown is just as acceptable as tail recursion.  I do
Kent> so tire of having to de-program Scheme converts from believing
Kent> that only the Scheme-style

; (let loop
;     ((input list)
;      (output '()))
;   (if (null? input)
;       (reverse! output)
;       (let ((entry (first input)))
;       (let ((name  (person-name entry))
;             (age (person-age entry)))
;         (loop (cdr input)
;               (cons (list name age) output))))))

Kent> is acceptably clear.

Kent> Among other things, this contains a lot of verbiage which is
Kent> subprimitive to what's being accomplished, such as the need to
Kent> maintain an extra loop variable for the list being traversed,
Kent> and another for the result being accumulated, not to mention the
Kent> programmer having to know the stupid trick about consing up a
Kent> list backward and then reversing it, which though good "world
Kent> knowledge" for a programmer to have really isn't relevant to the
Kent> domain task at hand.  And, of course, Common Lisp doesn't have
Kent> tail recursion elimination, so to avoid possible stack overflow
Kent> in the case of long lists, the Scheme loop above would have to
Kent> at least be rewritten using DO (which is effectively a sugaring
Kent> of a tail recursive loop). But LOOP hides these "implementation
Kent> level" extra variables, the knowledge of accumulation tricks,
Kent> and certain potential "stack" issues and other traversal
Kent> strategy issues in a way that I have over time come to agree
Kent> with LOOP proponents is expressionally important.

Kent> So in a sense, I think Lisp is closer than Scheme to your stated
Kent> goal of avoiding places where "where control vars are peppered
Kent> throughout the code".

I certainly agree with you that the "feel" of the LOOP-based version
of this is _vastly_ nicer than the "hand-coded tail recursion."

I would suggest the thought that the popularity of the latter falls
out of three considerations:

a) Scheme is presented as an academic language, and the quality of
   teaching will not be uniformly wonderful.

   It is *certainly* going to be used as a tool for teaching
   recursion; a _good_ course might move on to present iteration, but
   would do so as a secondary matter.  "Questionable" courses may
   never get around to indicating that you can represent structures in
   an iterative way.  Only an *excellent* course would promote the
   equality of iteration and recursion.

b) Presentation of _both_ iteration and recursion and the "software
   engineering" side requires more time than may get devoted to
   Scheme.

   In a brief two week module on "Lisp," it's hard to get past the
   prejudices of Lisp being basically about recursion and lists.

   Moving on to a _truly_ fuller view takes further time.

c) Macros aren't crucial to Scheme the same way they are to Common
   Lisp.

   This too is related to a) and b); a shallow examination of "Lisp,"
   in _whatever_ form, won't get around to the relatively advanced
   topic of macros.

   Schemely support for macros is not uniform, and there
   are a couple of competing macro systems.  On the one hand, this
   does not encourage their use.  On the other hand, it does not
   encourage usage of facilities that _require_ their use.  [LOOP
   being the "pathological" example of this...]

   In contrast, CL implements a considerable chunk of the language via
   macros, and the notion of the language being extensible comes from
   this.