Thanks greatly.  In literature, I often see LISP listed as a "Procedural" or
"structured" language rather than being grouped with languages refered to as
"Object Oriented", hence the question.

This question is roughly analagous to asking:
  "Is there an Object-Oriented version of C++?"

cor

New Flavors, done by Dave Moon (then at Symbolics) was
done c. 1984 was a re-implementation of Flavors that used
a generic function paradigm, but did not include multi-methods.

- Frame Languages (based on the ideas of Marvin Minsky)
- Actors (based on the ideas of Carl Hewitt)

http://www.parc.xerox.com/istl/members/stefik/loops.html

  There have been no non-object-oriented versions of Lisp at least
  since the mid-1980's.  (Not counting Scheme as a version of Lisp.)

  If you take the definitions of object-orientation seriously and
  don't get distracted by current implementations, Lisp has in fact
  _always_ been object-oriented, meaning specifically that objects in
  Lisp have identity and that functions and methods on Lisp objects
  refer to their type to decide what to do with them.

  The Common Lisp Object System (CLOS) is a full-fledged, very mature
  implementation of the concepts of object-orientation, and it has
  been part of the Common Lisp language since the early 1990's and has
  been available for it since the mid-1980's.  Other systems have also
  been found lurking within Common Lisp systems, such as Flavors.

  What have you been missing or not finding?

Furthermore, the language taxonomists may not be familiar with the details
of all the Lisp dialects, or may base their classifications on what they
knew about the language a decade or two ago.

The original meaning of "object oriented" meant "oriented around the idea that
everything is an object".  When you delve deeper into this, you find quickly
that the only really true key to what that means is that (a)
all data is perceived as an object [which is incidentally not true of Java,
where there is data like int, float, etc. that are really not properly objects]
and (b) where an object's identity is central to its being.  [This is also not
true of many so-called modern object-oriented languages.  That is, you
frequently get "call by value objects" where if I take an argument of type foo
and you hand me an object of type foo, I might get a copy of your object rather
than a pointer to it.]  

In the more modern (and I think more broken) definition of "object
oriented", everything revolves around the idea of "encapsulation" and
whether there are certain properties of being able to expose or not
expose implementation, etc.  for the purpose of inheritance or client
use.  This is a useful concept but really has nothing to do with
traditional object orientedness.  Traditionally, I claim Lisp has been
object-oriented even in dialects where you couldn't define new classes
nor influence inheritance behavior in any way.  That's because in such
dialects identity was central, all arguments were passed by pointer,
and object identity was the name of the game.

The notion of being able to extend an object oriented class system is
useful but is not central.  Moreover, it's a data abstraction
violation (at the meta level) to say that a language is programmed in
a certain way internally to its structures.  To make your language
definition depend on offering a model that imposes such an abstraction
violation (asserting that what should not matter--implementation
details--is central) seems silly to me.  

ANSI CL is not, IMO, the only object oriented lisp.  All lisps are object
oriented.  The notion that encapsulation defines what OO is is just silly.
And the notion that C++ is OO just because it uses some form of
encapsulation is downright laughable...  C++ has numerous ways in which it
really is not, IMO, OO.  It sacrifices "identity" in too many places, not only
in calls but also in the sense of its overly emphasizing static analysis of
what an object's type will be rather than waiting until runtime; Java fixes
some of this but not enough.  The result is still that a method's "prejudice"
about an object's type will often supersede better judgment that would come
from actual inspection of the object's type and methods.  Static dispatch is
just too early to make wise decisions, and in a world that is ever more
dynamic, this is not a positive trend in language design.

How does Simula and CLOS compare?  And which historical links are
there between the two?  Is Simula alive in any sence?

http://www.iro.umontreal.ca/~simula/

http://www.isima.fr/asu/

http://home.sol.no/~simula/

- and GNU Emacs of course has a Simula editing mode, and there is at
least one free Simula compiler for Linux (cim) :-)

(Haven't used Simula myself since -83, but I used to like the language.
Relates to Algol-60 approximately as C++ to C.)

Guy>  I vaguely remember about 10-15 years back the term 'object
Guy>  based' being used.  As far as I recall the term used was used to
Guy>  describe languages such as Ada.  From what I can remember
Guy>  'object based' was some kind of subset of 'object oriented'.  I
Guy>  haven't run into the term for a long time now, and was wondering
Guy>  if it is still used and if so what the distinction is between OO
Guy>  and object-based.  Just idle curiosity...

IIRC Grady Booch in his book[*] _Object_Oriented_Design_ used 'object
oriented' and 'object based' terms to distinguish between languages
that do support full 'magic set' of object orientedness
(encapsulation, inheritance...) and languages providing only some
subset of it.

--
  Eugene

Ah, yes. Some of us still have fond memories for Simula.  Also see
<URL:http://pdp-10.trailing-edge.com/www/lib10/0242/>:

        POOMAS: Poor Man's SIMULA, Version: 1, June 1972
        ...
        Abstract: POOMAS is a collection of subroutines, macros,
        etc. which allow a programmer to write SIMULA-like simulation
        programs in BLISS. The POOMAS routines will handle queues,
        sequencing, random number generation, etc.

It used the BLISS built-in "EXCHJ" (exchange jump) coroutine call
operator for light-weight threads, since each Simula object was
also (potentially) a thread.

In 1983, Bakul Shah & I (at Fortune Systems) built a set of C libraries
[presented at USENIX 1984] that did almost the same thing as POOMAS, and
used them for simulations somewhat in the spirit of Simula. An "object"
was a coroutine or "thread", that is, some subroutine with an (potentially)
infinite loop in it [that provided the behavior of the object] and a piece
of heap-allocated stack [that provided the state of the object, or instance
slots, if you prefer]. Library calls could "wake" other threads/"objects",
or could "sleep" waiting for events or the passage of (simulated) time --
any such sleep of course resulted in a coroutine call to the next available
thread/object that was ready to run. During their lives, objects could
create (and destroy) other objects, emit or receive messages, etc., etc.

So you definitely *can* do "object-oriented programming" in C...  ;-}  ;-}

-Rob

Btw., Ole-Johan and Kristen recently got the rank of commanders of the
Order of St. Olav, the highest rank a civilian can get in Norway, for
their contribution to the early research into object orientation.

How might one rank LISP when viewing it in terms of the "high level" vs.
"low level" continuum paradigm?

Like unto the previous question:

Does LISP have pointers, memory allocation, the like?

Thanks again for your patience and generosity with my curiosity about LISP.

(Pointers to good books (especially beginning treatises) on LISP
programming, references, tutorials, web sites, etc. would be very greatly
appreciated.  I'd like to start my relationship with LISP off on the
proverbial right foot.)

Perhaps there are some other terms for this out there?

If you think that there is a fixed way of describing what "object
oriented" means, then you probably have only worked with one language
"with objects," and probably only with C++...

If you want to get a feel for the "taxonomy," you should look to:

a) Simula
b) Smalltalk
c) LOOPS
d) Flavors
all of which were amongst the early "object systems."

Lisp systems have been known to include assemblers, exemplified in the
literature in Peter Norvik's book "PAIP" which presents a section on the
construction of a Lisp compiler by compiling code using an assembler
that is part of his Lisp implementation.

At the other end of the scale, Lisp is used to do, in the very same
book, artificial intelligence applications that provide _very_ high
level abstractions.  Norvik's Othello implementation, for instance,
plays a quite credible game of of Othello; given enough CPU and
memory, it can likely outplay most human players.

Mind you, both pointers and memory allocation are largely kept
"behind the curtain" in the vast majority of cases where you don't
truly need to worry about them in that memory is managed using a
garbage collection system.

  Ignorance has only one cure: Asking questions.  Keep it up.

| How might one rank LISP when viewing it in terms of the "high level"
| vs. "low level" continuum paradigm?

  All over the range.  Lisp as such has no limit downwards -- you can
  refer to any kind of object you want.  Since you can expand the
  language any way you want, including optimizing the syntax for a
  special language, there is no limit upwards, either.

| Like unto the previous question:
|
| Does LISP have pointers, memory allocation, the like?

  Yes, Lisp has pointers.  No, you never see them, and you can't do
  arithmetic on them, and you never dereference them.  That is, any
  object you deal with is actually a pointer to the object.  The only
  exceptions here are characters and small integers.  (If you really
  want to, you can use functions that come with most implementations
  that allow you to reference memory directly through an integer or
  special raw-machine-address thing.)

  Yes, Lisp has memory allocation, but just like the pointers you
  don't see, you don't ever see the memory allocation.  In Lisp, we
  allocate objects, not memory.  That is, there is no such thing as
  raw, uninitialized memory to which you only have a machine address.

  Yes, Lisp has the like, too.

| Thanks again for your patience and generosity with my curiosity about LISP.

  No problem, but if you spell it "Lisp", you will also have entered
  the 1990's.  Small caps went out of vogue in the publishing world
  sometime between 1988 and 1992 as far as I can tell, so now it is no
  longer customary to write UNIX, FORTRAN, LISP, COBOL, etc, in small
  caps like they were in their original literature, but Unix, Fortran,
  Lisp, and COBOL (some things just don't improve :).

| (Pointers to good books (especially beginning treatises) on LISP
| programming, references, tutorials, web sites, etc. would be very
| greatly appreciated.  I'd like to start my relationship with LISP
| off on the proverbial right foot.)

  Take a look at www.lisp.org (= www.alu.org).

| Is there an FAQ for this newsgroup?

  Yes.

  Which, by the way, wasn't the truly interesting bits.  Simula had
  garbage collection, coroutines, and supported simulation, hence the
  name.  Bjarne wanted to do simulation, but, due to his proximity to
  the C world, wanted to do it in a C-like language.  None of the
  stuff that supports simulation in Simula survived into the C world.

  The kind of object system that Simula has is fantastically optimal
  for manipulating objects in a simulation.  It is simply brilliant.
  However, if you don't do simulations of mostly real-world things,
  the object paradigm doesn't really work, the encapsulation stuff is
  more of a hindrance than a support, and the inheritance mechanisms
  don't make much sense being the exclusive approach.  So Bjarne took
  all the bits that made Simula good for simulation, junked all the
  necessary support systems needed for simulation, and ended up with a
  model that doesn't really fit his support framework (which only does
  object creation and destruction and rudimentary type dispatch), only
  to have to add something so incredibly retarded as Templates because
  he failed to grasp what he had left out in his desire to copy Simula.

  Bjarne claims to credit Simula, but C++ is a discredit to Simula if
  it pretends to have learned from it.  Simula's pioneering work in
  object orientation for simulation deserves a legacy, not something
  so miserably idiotic as C++.