Subject: Re: That place.. (was: How to make a mutually recursive macro and   function)
From: Erik Naggum <>
Date: 2000/03/06
Newsgroups: comp.lang.lisp
Message-ID: <>

* Christopher Browne
| What it *really* says is that Scheme has some significant differing
| underlying assumptions from Common Lisp.

  we all know this to be a deep and fundamental truth, already.

| b) The "call/cc thing" parallels the "tail recursion thing" where
|    Scheme requires that implementations have some common primitives.
|    CL requires no such thing, which provides implementors greater
|    flexibility, but which diminishes some of the expectations on how
|    things work that can be made with Scheme.

  this is also one of the differences between the Scheme and the Common
  Lisp communities.  the Scheme community uses the specification as the
  source for its expectations and when it can't find something in the
  specification for Common Lisp, claims that Common Lisp cannot expect it.
  the Common Lisp community uses the specification and the common sense of
  vendors and the functioning of the market as its source of expectations,
  and consequently doesn't have a problem with any of the things that
  Scheme people have problems with in Common Lisp.  on the other hand, the
  Common Lisp community recognizes the Scheme community's need for its very
  thin specification, and argues that the Scheme community cannot expect to
  have any useful functions in a Scheme environment at all, to which the
  Scheme community always responds that every Scheme implementation has a
  lot of goodies that you can rely on, and then there's slib and whatnot,
  so in the end it seems rather specious of the Scheme adherents to argue
  that the Common Lisp community cannot expect tail-call merging, which
  every implementation offers given sufficent optimization settings.

| c) The *problem* with Scheme (which the SRFI process may help remedy)
|    that the "call/cc" thing shows off is that call/cc was intended to
|    be treated as a *primitive* that would be used to implement control
|    structures.

  and Common Lisp has all those control structures that Scheme people
  implement with call/cc.  it's like giving programmers access to a
  primitive of creating, linking, and unlinking call frames, but no
  function call primitive.  (Scheme doesn't have funcall, as you know. :)

| In short, it's not that call/cc is particularly bad, it's that call/cc is
| merely a primitive, and isn't widely useful until you use the primitive
| to build specifically useful structures.

  which implies that the usefulness of implementing these control
  structures with call/cc has to be questioned, since none of the Common
  Lisp implementations even use the primitive operation call/cc underneath,
  and they also don't generally heap-allocate call frames, but remain with
  the stack-allocation paradigm.  in short, call/cc is a primitive that is
  too primitive for its own good: it demands a particular way to do things
  that doesn't reflect how people have come to conclude they should be
  done.  the same is true of Scheme's tail calls.  it doesn't make sense to
  force every tail call to be a jump, as it messes with argument passing
  conventions and stack unwinding and many forms of debuggability and a
  host of other issues tha makes communication with other languages hard.

  so in my view, Scheme's core function call model is simply a mistake, and
  both tail calls and call/cc make the design mistakes explicitly visible
  to the users.  learning from such mistakes is an important part of moving
  forward in language design, and this may indeed be why no other language
  has picked up on these ideas, despite having picked up on a number of
  other valuable contributions from Scheme.  some of this reflects badly on
  "adjacent ideas" in Scheme, too.

  again in my view, there are probably mistakes in Common Lisp's design
  that makes it hard for people to pick up on adjacent ideas, too.  for one
  thing, I have started to believe that the use of upper-case symbol names
  is a serious communications bottleneck with other languages that we need
  to talk to these days.  it's not that we can't overcome it, it's that
  it's such a hassle to overcome it.  and it's not a technical issue, just
  like start-up time is not a technical issue, it's a matter of perception
  and how we approach contrary views when they necessarily come up.