Subject: Re: Why is Scheme not a Lisp?
From: Erik Naggum <erik@naggum.net>
Date: Sat, 16 Mar 2002 02:18:17 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3225233908428331@naggum.net>

* William D Clinger
| Yes, you are.  I was talking about the fact that the defining feature of
| Lisp2, separate environments for values and for functions, creates a bias
| against higher-order thinking.

  No, it does not.  This is completely bogus reasoning.  And if it is your
  gripe with funcall, which seems to be a standard problem for Scheme
  freaks, even though they have _apply_ just as Common Lisp does, I have
  posted a macro called "with-functions" that effectively removes the
  funcall from sight and declares the variables as functions.  This should
  shift the bias back in the favor of "higher-order thinking".  That macro
  took me seven minutes to write, debug, and test (,', always confuses me).
  The distance between a Common Lisp and "higher-order thinking" is thus
  seven minutes of my time, and a google search and cut-and-paste for you.
  Please quit griping about this non-existing problem.

| In Lisp2, functions are usually bound in a different environment from
| other values, so Lisp2 programmers do not think of functions simply as
| values.

  This sounds totally bogus.  It certainly does not follow from the premise.

| Thus, for example, you can find examples of Common Lisp programmers who
| do not see the need for hygienic macros, claiming that function names
| cannot be shadowed.
 
  You can find examples of absolutely anything, and if you include jails
  and mental hospitals, even more, so this must be the weakest of all
  possible ways to express a criticism.

  It probably surprises you to learn that symbols in the common-lisp
  package cannot be defined or bound in a conforming program, so it is
  actually _true_ that "function names cannot be shadowed" (which is a very
  strange way of saying it. but I can sort of reverse-engineer the proper
  meaning from it).  At least a macro can expect the standard environment
  to apply, and I believe macros should do just that, and if they require
  additional environments, they should use symbols in a package over which
  the macro author has control.

  Because of packages and the restrictions on using symbols in the
  common-lisp package, there is no need to ensure that you have the right
  definition of any symbol in the common-lisp package with a function
  definition.  This, if you bind a variable "list" in Scheme, you have
  clobbered the standard function "list" for the body of the form that
  binds it, but if you try to name a local function "list" in Common Lisp,
  you already have an error in your program, one that a compiler should be
  reporting to you.

| Are they unaware of FLET and LABELS?  Probably not.  Probably they're
| just aware that FLET and LABELS are so seldom used as not to cause a
| problem for macro writers.

  Are you unaware of the restrictions on symbols in the Common Lisp
  package?  If you are, please see ANSI X3.226-1994 11.1.2.1.2.

| Why aren't FLET and LABELS used?  There are many reasons, but one is the
| cultural bias against higher-order thinking that results from a Lisp2.

  Nonense.  It does not result from a Lisp-2 at all.  That is just a stupid
  argument that Scheme freaks like to offer, and it is so goddamn _stale_.

| If you still don't get it, consider what it is like to simulate higher
| order functions using function objects in Java.  To call a function
| object f, you use a special syntax such as f.call(_) instead of writing
| f(_).  The .call can be viewed as a kind of cast that coerces from the
| value domain to the function domain.  Common Lisp's FUNCALL can be viewed
| as a similar coercion.

  HELLO!?  I PUBLISHED A MACRO THAT REMOVED FUNCALL FROM VIEW SO THAT YOU
  FUCKING OBNOXIOUS SCHEME FREAKS NO LONGER HAVE ANYTHING TO WHINE ABOUT!
  YOU MORONS HAVE SPENT *YEARS* WHINING ABOUT THIS, YET IT TOOK ME NO MORE
  THAN SEVEN MINUTES TO GET RID OF IT AND CONFLATE THE NAMESPACES FOR A
  SPECIFIC LIST OF VARIABLE NAMES.  What does this show, _other_ than that
  Scheme freaks are _much_ more interested knocking and denigrating Common
  Lisp than doing anything useful and constructive?

  If you still do not get it, figure out that Common Lisp has the power and
  capacity to change its syntax so it can accomodate such perversely anal-
  retentive needs as removing an operator from sight (even though you
  _still_ need apply).

| Many of the people who are attracted to Lisp in the first place don't
| like to clutter their programs with all these injections and coercions
| from one type to another.

  If they had anything approaching a usable intelligence, they would figure
  out how to write the macro I wrote, and I did not even have a problem
  with funcall to begin with, I was just so goddamn tired of the useless,
  incompetent whining from people who were so clueless they could not even
  write a little macro to get what they wanted.

| They're annoying and unnecessary.

  No, this is a conclusion about Common Lisp drawn from Scheme premises.
  Common Lisp is not a dialect of Scheme.  This is _precisely_ what this is
  all about.  You Scheme freaks are so full of yourself that you cannot
  even see that other people are _able_ to make other design choices than
  you have.  You think everything other people do is _wrong_, do you not?
  Some of you guys sure act like you have a one-bit right/wrong flag, and
  of course you do nothing wrong, so therefore what other people do must be
  _wrong_, since it is not what you do, and what you do is _right_.

  Common Lisp programmers do not regard this the same way you do.  _If_
  they do, they write something like the macro I wrote.  There _is_ no
  problem to a Common Lisp programmer -- a beginner would ask if it could
  be fixed and an experienced Common Lisp programmer would just do it.  It
  is _only_ a problem to Scheme freaks who have a grudge against Common
  Lisp and want to confirm their delusions of superiority to themselves.

| If you're a first- or second-order thinker, then you probably won't agree
| with this, and you'll be happy with a Lisp2.  If you're a higher-order
| thinker, you'd be happier with a Lisp1 if all else were equal.

  Lisp-1 and Lisp-2 have nothing whatsoever to do with this issue.  Even
  funcall is a non-issue.  What matters is probably what Kent Pitman has
  been hinting at: People who want a one-bit universe where purity and
  elegance and such follow very simple rules are much more attracted to
  functional programming languages _and_ Lisp-1.  You have the causality
  all wrong, here, and this is quite obvious: People are not _naturally_
  "higher-order thinkers", but there is much evidence to support a view
  that some people have a hard time dealing with "horizontal complexity"
  and much prefer "vertical complexity" on very small initial space.  These
  two types are fairly incompatible.  A vertical complexity guy will look
  at a horizontal complexity guy and think he is not superskilled in
  anything and therefore untrustworthy and useless (many academics fall
  into this trap), whereas a horizontal complexity guy who meets a vertical
  complexity will be stunned how little he knows about the world about some
  corner of which he has this astonishing amount of knowledge.

  Now, the most interesting thing happens is when they meet one of their
  own type: A vertical complexity guy will trust another and defer
  authority to him automatically in his "area", thinking (1) that he, too,
  has spent a lifetime in some incredibly small area, and (2) that you
  cannot go wrong if you study something long enough, especially not if
  some accredited university has granted him a degree.  However, those who
  master horizontal complexity much more easily, generally display an
  amazing amount of insight and knowledge in many areas, draw analogies
  from all kinds of areas, and they can communicate with others who master
  horizontal complexity with ease and can understand, not trust, those who
  have more knowledge in one area than another, because their knowledge is
  integrated into a system intended to mirror the world they experience.
  The vertical complexity guys have built their "system" from axioms and
  theorems that others have provided, before they may be able to provide
  their own deep insight into something that requires extremely specialized
  skills to appreciate.

  I suspect that functional programming (and Scheme) appeals to those who
  find that they master vertical complexity more easily and dynamic
  programming (and Common Lisp) appeals to those who find that they master
  horizontal complexity more easily.  However, this is _NOT_ (repeat: NOT)
  a one-bit flag in your personality.  But, *sigh*, what's the use?
  One-bit people are going to respond as if it is, as I have I created but
  two pigeonholes and want to stuff all of mankind into one of them, anyway.

///
-- 
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.