The problem is that the instances we have actually seen rarely (if
ever) provide expressiveness not possible in the "one dimension" of
text, but rather provide some visual representation precisely useful
to conveniently represent some limited domain, for instance, that of
linking together lab instrument components.

We see:
 - E/R diagrams, to describe relationships between database fields;

 - Class diagrams, to similarly describe particular relationships
   between objects in an "object system;"

 - Sometimes diagrams to describe physical relationships between
   physical objects (as is the case with LabView, and as was the case
   with some continuous system simulators (essentially DE solvers).

The benefit I'd think you'd get out of the extra dimension would be
the ability to more easily describe linkages between objects.

But it's hardly a problem to describe arbitrary linkages between
objects with the "one dimension" of the semi-infinite line of text.

Whether it's in BASIC, with:

10 REM
20 DIM A(10)
30 A(1) = 5
40 GOTO 30
50 END
60 REM OOPS - the reference in 40 prevents this from terminating

  char *p;
  p = some_string;

or references of HTML:
  <a href= "#refinthisdoc"> internal reference </a>
  to <p> <a name="refinthisdoc"> some chunk of text

or references in Lisp:
  (let ((a 1)
        (b 2))
     (format t "Display value referencing a:~A and b:~A~%" a b))

there is no paucity of ways of doing crossreferences between objects.
They are of varying aptness, but they're certainly there, and there
are a _lot_ of idioms to indicate references in Plain Old Text.

Visual programming (and I refer not in the _slightest_ to the
often-sold-by-Microsoft tools that put thin GUIs on top of text tools)
still sits at the research stage, at least vis-a-vis anything
attempting any kind of generality.

On the one hand, propagation of the alt.* hierarchy is somewhat
dubious.

Just trying to keep the discussion from getting too "heavy" here.

Another S-exp -style language would be one of the internal
representations in the gcc compiler.

sl

  Grow up.

| According to the charter of the newsgroup, it's for all dialects of Lisp.

  comp.lang.lisp has no charter.  Newsgroups are what the users make them.

  Lacking a forum for arc, and providing its purpose is to build rather
  than destroy, I can think of no better forum than comp.lang.lisp for it
  until it gets its own forum and community.  When you have new forum all
  to yourself as a new community, the whole purpose is to confine articles
  to that forum, not clutter up whichever forum you split off from with
  useless whining that you did not "really" mean to split off.  However, if
  Scheme had, hypothetically, had no forum of their own, I certainly would
  have done everything I could to help create it, so the obnoxious, anal-
  retentive, one-bit, purity-before-usefulness people could go away there.
  So far, Arc seems only to suffer from bad taste.  That would be OK, at
  least for a while.

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

  I had to look this up after I posted it just to be certain that I had not
  screwed up.  My Tenth Edition Merriam-Webster Collegiate Dictionary says
  elephan also means "One that is uncommonly large and hard to manage",
  which I think Scheme actually becomes once you tro use it.

  Incidentally, the elephant family is called Elephantidae, the only family
  of the order Proboscidea.  "Pachyderm" is an unscientific term, referring
  to "animals with thick skin", including such diverse animals as elephant,
  rhinoceros, and pig.  One emay conclude that Scheme freaks are not
  pachyderms in either literal or transferred meaning, but other than that,
  "pachyderm" has little use as a term.

  The good old WAIS sources appeared to be using Common Lisp syntax using a
  format like (:source {<keyword> <value>}*).

(I'm saying that is what happened historically.  Whether CL or Scheme
should still be regarded as a Lisp is a different question, one that
has less to do with facts than with desires.)

Most OO languages are basically second order (objects, methods), and
they are the popular languages today.  Thus CL, itself an OO language,
fits the Zeitgeist.

Meanwhile the Scheme community has found common ground with Standard
ML, Haskell, and other languages where higher order functions are
prominent.

I believe the differences between the CL and Scheme communities have
much less to do with how well they adhere to someone's idea of a Lisp
ideal than with the second-order/OO versus higher-order/functional
issue I have tried to describe here.

Let me hasten to add that, in my opinion, CL is indeed within
the Lisp family of languages, and that I strongly suspect that
John McCarthy holds a similar opinion.

By contrast, Scheme doesn't really primitively offer OO, prominent or not.
Certainly it doesn't keep someone from layering it after, and to some degree
that's the intent of the language, that such stuff be the stuff of libraries.
But, at least from my (and probably many CL folks') point of view, it isn't
so much that this limits capability as that it robs the Scheme community of
a common terminology for talking about types.

The place where the language family metaphor breaks down is where we start
to talk about libraries.  The question is where the line is between libraries
and other user data, especially in a language that makes the libraries data.
Because libraries can be incompatible.  And not everyone knows every library.
So it calls into question what it means to "know Scheme" or to be
"Scheme-like" since there are almost no required features of Scheme; it is a
chameleon which, to put things in probably overly-provocative terms for point
of discussion, can claim anything but promise nothing.

Often people make lists of what Lisp is for the purpose of introductory
courses.  And often that list contains "program is data".  Of this my
standard reply is to observe that many languages can represent themselves
quite easily. BASIC can (arrays of strings).  Machine language can
(a range of memory).  What sets lisp apart isn't that it _can_, which is
easy to guarantee in a Turing powerful language, but that it _does_.
The power, I claim, is in Lisp's willingness to be arbitrary.  Scheme has
grudgingly recently allowed a very carefully concocted EVAL model back into
the language after years of absence.  Meanwhile, Lisp has gone on to add myriad
arbitrary new things, like a type system, a condition system, and so on.
These add capabilities, yes, but Scheme could add capabilities.  The power
really added is terminology--names for things we know we all have. Names
that are an attempt to create a common base that everyone uses.  To me, it's
the very arbitrariness that I sense the Scheme community eschews, and that
gives CL its power.

If you wanted a technical difference, I suppose I'd drive my stake in the
ground on that one.  Emacs Lisp, likewise, exploits the arbitrary.  There
could be many ways to do key bindings, but that would do no good to a vast
community of people needing to cooperate.  So specific, perhaps even flawed,
but "good enough" mechanisms exist for organizing tables of key bindings and
turning them on and off by mode.  And these are part of what it is to be
that Lisp, not just "extra libraries you might happen to load".  AutoLisp,
Interlisp, and even Maclisp did this.  

Scheme people have, by contrast, sometimes questioned the need even for an
ERROR function, claiming "Isn't it already an error just to call a function
named ERROR? What more do you need?"

If there is a conceptual Lisp with axioms, this is like having an algebra,
or group in mathemetics.  This goes to other discussions about the language
behind "Is Scheme a Lisp" as opposed to "Is Scheme a dialect of the family
of Lisp languages".  One can say that "Set1 is an Algebra" or the "Set of
Reals is a Field".  "Scheme is a Lisp" would then have meaning.

My background is not in computer science.  Is there a set of Lisp axioms?

Something like:

1) There exists a set of symbols S.  Any symbol s {an element of S} can be
bound to a value v (represented by (s,v)).
2) For any symbol s with value v there exists a binding function B, such
that B(s v)->(s,v). SETF
3) There exists an identity function such that I(s,v)->(s,v). IDENTITY
4) There exist values (v1 . v2) which are structured composites of two
values v1 and v2. CONS.
5) There exists an operator = such that (s1,v1)= (s1,v2) iff v1 is v2.  EQ.
........

I'm not sure Scheme people think it's involved in a quest for the HGCR
however.  That's *almost* right, but not quite.  Scheme people
probably agree it's a mirage, but they are after something slightly
different, albeit very close.

The Scheme goal is perhaps not to find the HGCR, but to only add
language features that we are Really Confident belong to the HGCR.
For a long time it has been clear that macros are part of the HGCR,
but they weren't going to be added to Scheme until a "problem free"
definition, a Canonically Right one, if you like, was found.

Common Lisp, by contrast, knew that macros are really important,
greatly desired, and that people can do Just Fine, Thank You with a
macro facility even if it isn't Canonically Right.  And the Common
Lisp people are certainly correct about that.

Scheme is about, among other things, trying to avoid the "carrying
around old mistakes" problem.  There are a lot of small, relatively
inconsequential areas where Common Lisp has curious little
inconsistencies (like the difference between the way plists and alists
work, for example)--the inconsistencies don't matter much, but there
they are.

So the Scheme goal is try really hard to never have to say "oh, shoot!
I wish we'd done it differently!  but we'll keep it because it's good
enough."  My GNU/Linux system *still* has a function called "creat"
because of this, and Scheme is about trying not to do that.

As you so rightly point out, Common Lisp, by contrast, is about trying
really hard to maintain compatibility, to provide a standard namespace
for all the things any complete system will have, and so forth.  Those
are also hugely important tasks.

Some things that CL might profitably borrow from Scheme would be
proper tail recursion and hygenic macros.  Call/cc too, but of course,
that's not ever going to happen for all the obvious technical reasons.

I'm not sure what kind of control you mean, however, so I don't know
what exactly the issue is that you're worried about.

  CAN YOU GROW UP!?  You are regressing so fast you will be unborn in three
  weeks if you keep up this idiotic childishness.  Curb your anger and act
  like an adult!  Almost all the morons in this newsgroup resort to such
  obgiously retarded attacks when they do not get _their_ will around here,
  but not getting your will does not mean that somebody else gets theirs
  all the time.  One-bit people like you _really_ need to acquire more bits.

  Do you think you can figure out the difference between "I do _not_ want
  you pathetic, whining Scheme freaks here when you have your own stupid
  playground" and "I want to contol what _does_ go here"?  If cannot, you
  must be _fantastically_ dense.

  Once again, we must ask what the Scheme freaks seek in posting their
  idiotic drivel to comp.lang.lisp.  It looks a lot like a very childish
  desire to be accepted by their parents or grade school teacher or some
  other such authority, and when rejected, they turn to making a hell of a
  noise in the hopes of at least getting attention.  Grow the fuck up!