* "Esteban" <····@catfish.net>
| Is there an Object-Oriented version of LISP?
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?
#:Erik
--
I agree with everything you say, but I would
attack to death your right to say it.
-- Tom Stoppard
Thanks, everyone, for the very interesting responses.
As you can see, I know little about LISP.
I appreciate your kind and helpful responses to my question.
It is quite unusual to ask a question on a newsgroup and not be flaggelated.
I appreciate it. Would that all ng participants were so helpful.
In our last episode (Tue, 24 Oct 2000 22:39:26 -0500),
the artist formerly known as Esteban said:
>Forgive an ignorant question:
>
>Is there an Object-Oriented version of LISP?
Common Lisp was one of the first languages that was standardized with
"Object Oriented" capabilities. The only other language that might brag
of having OO earlier might be Ada.
This question is roughly analagous to asking:
"Is there an Object-Oriented version of C++?"
You should avail yourself of the Common Lisp HyperSpec, particularly
the section on CLOS:
<http://www.harlequin.com/books/HyperSpec/Body/chap-7.html>
--
········@ntlug.org - <http://www.ntlug.org/~cbbrowne/lisp.html>
The large print giveth and the small print taketh away.
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.
"Christopher Browne" <········@knuth.brownes.org> wrote in message
····························@knuth.brownes.org...
> In our last episode (Tue, 24 Oct 2000 22:39:26 -0500),
> the artist formerly known as Esteban said:
> >Forgive an ignorant question:
> >
> >Is there an Object-Oriented version of LISP?
>
> Common Lisp was one of the first languages that was standardized with
> "Object Oriented" capabilities. The only other language that might brag
> of having OO earlier might be Ada.
>
> This question is roughly analagous to asking:
> "Is there an Object-Oriented version of C++?"
>
> You should avail yourself of the Common Lisp HyperSpec, particularly
> the section on CLOS:
> <http://www.harlequin.com/books/HyperSpec/Body/chap-7.html>
> --
> ········@ntlug.org - <http://www.ntlug.org/~cbbrowne/lisp.html>
> The large print giveth and the small print taketh away.
"Esteban" <····@catfish.net> wrote in message
·······················································@lp.airnews.net...
>
> 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.
You will find that Lisp supports a great variety of programming styles. The
availability of alternate ways of thinking about (and coding) solutions to
problems is one of Lisp's many strengths. Lisp is one of the few really
useful multi-paradigm languages (and arguably the only one). It also
provides this capability in a way that does not compromise the elegance of
the language. Rather than being "listed as a 'Procedural' or 'structured'
language", it should be probably listed in a new category -- "Languages that
other languages aspire to be".
faa
"Frank A. Adrian" wrote:
> Lisp is one of the few really useful multi-paradigm languages
> (and arguably the only one).
What about OCaml?
--
Matthieu Villeneuve
Tumbleweed Communications Corp.
tel: (650) 216-2131
··························@tumbleweed.com
In article <··················································@lp.airnews.net>,
Esteban <···············@yahoo.com> wrote:
>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.
Well, not all Lisps are Common Lisp, so they don't all have the OO
features. The Lisp family in general is usually called "functional".
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.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Esteban <····@catfish.net> wrote in message
·······················································@lp.airnews.net...
>
> 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.
If anything, it's "Functional". But all in all, it depends how you use it.
You can code lisp which is basically imperative, or object oriented, or
completely functional.
-Mike
"Esteban" <····@catfish.net> writes:
> 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 is partly because in recent years the long-standing term "object oriented"
has been coopted from its original meaning and assigned a meaning that is both
not appropriate to the name and only 85% applicable to Lisp.
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.
JMO. But thanks for asking. It's an interesting question.
Btw, for more on this issue, see my Lisp Pointers article:
``What's in a Name? // Uses and Abuses of Lispy Terminology''
http://world.std.com/~pitman/PS/Name.html
Kent M Pitman <······@world.std.com> writes:
> "Esteban" <····@catfish.net> writes:
>
> > 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 is partly because in recent years the long-standing term "object oriented"
> has been coopted from its original meaning and assigned a meaning that is both
> not appropriate to the name and only 85% applicable to Lisp.
>
[lots of interesting stuff snipped]
I vaguely remember about 10-15 years back the term 'object based' being
used. As far as I recall the term used was used to describe languages such
as Ada. From what I can remember 'object based' was some kind of subset of
'object oriented'. I haven't run into the term for a long time now, and was
wondering if it is still used and if so what the distinction is between OO and
object-based. Just idle curiosity...
* "Guy" == Guy Footring <········@ford.com> writes:
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
[*] The last edition sucks: everything but C++ was stripped out.
Not considering the history and evolution of the terms, it has always struck
me that the term "object-oriented" at first hearing seems to suggest
"inclined or oriented toward objects" or "with some consideration for
objects". "object-based" seems to immediately suggest "based on objects".
Of course, hearing it this way is backwards. I wish there were a term for
"supports some kind of class definition system", as there are languages
like JavaScript and Visual Basic that support objects in some general ways,
but certainly aren't propertly OOPLs.
Perhaps there are some other terms for this out there?
"Eugene Zaikonnikov" <······@cit.org.by> wrote in message
···················@localhost.localdomain...
> * "Guy" == Guy Footring <········@ford.com> writes:
>
> 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
>
> [*] The last edition sucks: everything but C++ was stripped out.
In our last episode (Thu, 26 Oct 2000 20:38:22 -0500),
the artist formerly known as Esteban said:
>Not considering the history and evolution of the terms, it has always struck
>me that the term "object-oriented" at first hearing seems to suggest
>"inclined or oriented toward objects" or "with some consideration for
>objects". "object-based" seems to immediately suggest "based on objects".
>Of course, hearing it this way is backwards. I wish there were a term for
>"supports some kind of class definition system", as there are languages
>like JavaScript and Visual Basic that support objects in some general ways,
>but certainly aren't propertly OOPLs.
>
>Perhaps there are some other terms for this out there?
There are several different approaches to OO that are _substantially_
different.
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."
For the most part, the only part that people tend to be familiar with is
the stuff C++ inherited from Simula...
--
········@hex.net - <http://www.ntlug.org/~cbbrowne/linux.html>
Rules of the Evil Overlord #144. "I will order my guards to stand in a
line when they shoot at the hero so he cannot duck and have them
accidentally shoot each other. Also, I will order some to aim above,
below, and to the sides so he cannot jump out of the way."
<http://www.eviloverlord.com/>
* Christopher Browne
| For the most part, the only part that people tend to be familiar
| with is the stuff C++ inherited from Simula...
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++.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Please forgive another ignorant question about the nature and character of
LISP:
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.)
Is there an FAQ for this newsgroup?
"Esteban" <····@catfish.net> writes:
> Please forgive another ignorant question about the nature and character of
> LISP:
>
> How might one rank LISP when viewing it in terms of the "high level" vs.
> "low level" continuum paradigm?
i would place lisp on the high level side. however, lisp does have an
extensive collection of math functions and bit-banging functions found
elsewhere mostly in lower-level languages.
> Like unto the previous question:
>
> Does LISP have pointers, memory allocation, the like?
yes. the memory allocation is somewhat hidden. lisp does have
pointers, but most of that is hidden too. in lisp, symbols often take
the place of pointers (not counting C using pointers for iterators
&c).
> 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.)
>
> Is there an FAQ for this newsgroup?
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
In our last episode (Thu, 26 Oct 2000 20:33:11 -0500),
the artist formerly known as Esteban said:
>Please forgive another ignorant question about the nature and character of
>LISP:
>
>How might one rank LISP when viewing it in terms of the "high level" vs.
>"low level" continuum paradigm?
How do you want to view it?
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.
>Like unto the previous question:
>
>Does LISP have pointers, memory allocation, the like?
Of course it does. Only a FORTH system implemented on a PIC with
128 bytes of memory wouldn't have those things.
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.
>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.)
>
>Is there an FAQ for this newsgroup?
Paul Graham's "ANSI Common Lisp" is an excellent book on the topic.
For historical background and comprehensive and interesting material,
Guy Steele's "Common Lisp The Language," available from Digital Press
as well as in electronic form can let you get deeper. It is not
authoritative compared to the Common Lisp HyperSpec, but I find it
typically more useful due to the larger number of code examples.
--
········@hex.net - <http://www.ntlug.org/~cbbrowne/lisp.html>
When you open a bag of cotton balls, is the top one meant to be thrown
away?
* "Esteban" <····@catfish.net>
| Please forgive another ignorant question about the nature and
| character of LISP:
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.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Erik Naggum <····@naggum.net> writes:
> 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.
I prefer to first tell people that there are _only_ pointers, even to
fixnums etc. I then proceed to say that every implementation will
optimize certain pointers away. This is possible because you can not
modify the contents of a number or a character and thus you will never
observe this optimization (except when looking at performance).
Setting a variable then always means pointing it to another object,
for example, and all function parameters are pointers to objects.
Conceptually, there is no exception to the rule "everything is an
object and all object relationships are via pointers".
I think that this viewpoint helps to get the fundamentals right, but
it is of course still important to talk about the usual optimizations.
Marius Vollmer <···@zagadka.ping.de> writes:
> Erik Naggum <····@naggum.net> writes:
>
> > 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.
>
> I prefer to first tell people that there are _only_ pointers, even to
> fixnums etc. I then proceed to say that every implementation will
> optimize certain pointers away. This is possible because you can not
> modify the contents of a number or a character and thus you will never
> observe this optimization (except when looking at performance).
Now that Java has the same quality, it's easier to find that people
understand this. (I think it's Minsky that said that it's a necessary
condition to learning something is that you almost already know it. I'm
sure one of the people on here who manages important quotes can tidy this
one up for me. :-)
I think the important quality of Lisp (and Java) is not that it has
pointers or has "all pointers" but that it doesn't have "fractional"
or "improper" pointers. That is, you can't get pointers into things
that are object fragments.
Some Lisps, like the Lisp Machine, do allow this with some of their
si:%p- operations, which also allow pointer arithmetic, but I *think*
the reason this works is because the (a) the Lisp Machine has
operations that promote fixnums back to pointers and does not confuse
the two, and (b) it has a memory model that allows you to take an
arbitrary pointer, i.e. address, and do find-structure-header on it,
which allows the gc to figure out what is being locked by the
existence of a fractional/improper pointer. A lisp which allowed you
to drop arbitrary, unstructured memory into the middle of a page and
so could not inspect the structure of a page to recreate proper object
boundaries or couldn't tell if the page was only runover data from a
previous page would have trouble knowing what was locked by certain
pointers and would have to have a pretty conservative GC. Or so I imagine.
I've only done a few simple things with LispM pointer code since mostly
it's never ever needed (except to write the GC itself, etc.) but I once
spent some time doing the thought exercise of trying to guess how some of
this all worked and these were the issues that came to mind. I could
probably find out the real truth of all this from someone who knows if
anyone suspects me of being full of it on any of this...
Anyway, the ability to do fractional/improper pointers is in general, to
most users of Lisp, a liability because it means you can create--well, not
"garbage" which is a technical term, but certainly "junk". Maclisp allocated
type RANDOM to describe such. That was the type you got if you cdr'd into
things that you shouldn't have, or if you managed to get a pointer into the
second word of a symbol header or something like that. In other languages,
the terminology is probably just "bad pointer", but that's probably a misnomer
since often bad pointers come up as intermediate expressions on the way to good
ones in some computations, and that contradicts the normal mathematical
terminology of "bottom" which says that when you get to bad data, you can
never get back to good data.
The fact that Java flushed all this fractional/improper pointer junk was
certainly no accident and gives some credence to Lisp having done the same.
Since some Java designers were intimately familiar with Lisp, I'd bet
it's also probably no accident this good idea floated down from Lisp.
On the other hand, fractional/improper pointers do have their raw power. C
is not properly appreciated without understanding that it intends to be an
assembly language, capable of fully addressing the machine and implementing
things like Java. To say that C should have avoided pointers would probably
make little sense. And so to compare Lisp and C on the basis of the presence
of absence of these features is strange. Most Lisps, even those written in
themselves, have at their core a small kernel written in something else that
can do pointers in the more primitive C sense, even if not in C itself.
(e.g., the Lisp machine, which has no C at its core does have those pointer
operations I mentioned; Maclisp on the PDP10 had the assembly language Midas,
and so on.)
Kent M Pitman <······@world.std.com> writes:
> The fact that Java flushed all this fractional/improper pointer junk was
> certainly no accident and gives some credence to Lisp having done the same.
> Since some Java designers were intimately familiar with Lisp, I'd bet
> it's also probably no accident this good idea floated down from Lisp.
>
It could come from CL but I think it came from Modula-3. In the Java
specs a few articles on Modula-3 are mentioned and Java took a lot
from M3. (Garbage collection over multiple processes on remote
machines in RMI for instance.) Like Java, M3 has typed reference
values and a global REFANY type. Unlike Java but like Lisp Machine
Lisp, if you declare your module UNSAFE, you can use LOOPHOLE to get
at fractional pointers.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> > I prefer to first tell people that there are _only_ pointers, even to
> > fixnums etc. I then proceed to say that every implementation will
> > optimize certain pointers away. This is possible because you can not
> > modify the contents of a number or a character and thus you will never
> > observe this optimization (except when looking at performance).
>
> Now that Java has the same quality, it's easier to find that people
> understand this.
What? They've changed Java? When?
The necessity to have both int and Integer in Java has always been one
of its worst warts.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@world.std.com>, Kent M Pitman
> <······@world.std.com> wrote:
> > > I prefer to first tell people that there are _only_ pointers, even to
> > > fixnums etc. I then proceed to say that every implementation will
> > > optimize certain pointers away. [...]
> >
> > Now that Java has the same quality, it's easier to find that people
> > understand this.
>
> What? They've changed Java? When?
>
> The necessity to have both int and Integer in Java has always been one
> of its worst warts.
Sorry. I have elided additional text above (marked "[...]") to make my error
more plain. You're right that Java doesn't have this part all fixed.
But Java did fix the problem of not being able to get objects of type
"pointer to x" and not being able to do arithmetic on them to get into the
middle of an object. And people, I think, do understand the benefit of that.
So that's "less explaining", even if it's not "no explaining"...
Kent M Pitman <······@world.std.com> writes:
> I think the important quality of Lisp (and Java) is not that it has
> pointers or has "all pointers" but that it doesn't have "fractional"
> or "improper" pointers. That is, you can't get pointers into things
> that are object fragments.
The usual term in memory management is "interior" pointers, see
<URL:http://www.xanalys.com/software_tools/mm/glossary/i.html#interior
.pointer>. As you say, having none makes the garbage collector more
effective.
> Anyway, the ability to do fractional/improper pointers is in general, to
> most users of Lisp, a liability because it means you can create--well, not
> "garbage" which is a technical term, but certainly "junk".
It also means that since pointers correspond to objects one-to-one,
you can forget about them, and just think about first-class objects
that have identity -- a feature you praised earlier.
--
Pekka P. Pirinen, Adaptive Memory Management Group, Harlequin Limited
One thing that I have noticed is that all of these conspiracy theories depend
on the perpetrators being endlessly clever. I think you'll find the facts
also work if you assume everyone is endlessly stupid. - Brian E. Moore
In article <··············@zagadka.ping.de>, Marius Vollmer
<···@zagadka.ping.de> wrote:
> Erik Naggum <····@naggum.net> writes:
>
> > 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.
>
> I prefer to first tell people that there are _only_ pointers, even to
> fixnums etc. I then proceed to say that every implementation will
> optimize certain pointers away.
You could also say that (in a typical implementation) half of memory is
reserved to hold a pre-allocated copy of every possible integer with the
address of an integer n being, say, 0x80000000 + 4n. It's then a simple
optomization to say that:
a) you don't actually need to look at the memory to know which integer
it is, if a test is faster than a memory reference (as it is on modern
machines),
b) if you're not going to look then you also don't need to actually
store it
c) you can expand the integer range by a factor of four by using byte
addresses for the integers
d) if you don't mind restricting other objects to even byte sizes then
you can use the odd addresses for the "phantom" integer objects instead
of the top half of the address space, using the address 2n + 1 to
represent n.
-- Bruce
Thanks very much, everyone, for your generous responses to my questions.
I especially appreciate the links to Lisp tutorials.
I'll try to stop using all-ucase acronyms. Hard habit to break. (I quite
smoking, though.)
Perhaps this is a bad question. What Lisp might one recommend for the
beginner? For 32-bit Windows NT/2000? For Linux? Are there free or gnu
ones that are adequate for learning Lisp programming?
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * "Esteban" <····@catfish.net>
> | Please forgive another ignorant question about the nature and
> | character of LISP:
>
> 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.
>
> #:Erik
> --
> Does anyone remember where I parked Air Force One?
> -- George W. Bush
"Esteban" <····@catfish.net> writes:
>
> Perhaps this is a bad question. What Lisp might one recommend for the
> beginner?
It does not matter to much I think. Allegro Lisp, Lispworks etc. would
be good choices.
> For 32-bit Windows NT/2000?
Maybe Corman Lisp?
>For Linux?
Allegro, Lispworks, CMUCL, CLISP
> Are there free or gnu
> ones that are adequate for learning Lisp programming?
This question is anwered extensivly a in other threads.
Regards
Friedrich
--
for e-mail reply remove all after .com
Sorry.
"Friedrich Dominicus" <·····@q-software-solutions.com> wrote in >
> > Are there free or gnu
> > ones that are adequate for learning Lisp programming?
> This question is anwered extensivly a in other threads.
>
> Regards
> Friedrich
In our last episode (Sun, 29 Oct 2000 21:07:08 -0600),
the artist formerly known as Esteban said:
>Thanks very much, everyone, for your generous responses to my questions.
>I especially appreciate the links to Lisp tutorials.
>I'll try to stop using all-ucase acronyms. Hard habit to break. (I quite
>smoking, though.)
>Perhaps this is a bad question. What Lisp might one recommend for
>the beginner? For 32-bit Windows NT/2000? For Linux? Are there
>free or gnu ones that are adequate for learning Lisp programming?
On Windows, one of the nicer "Windows-friendly" implementations is
Corman Lisp.
<http://www.corman.net/CormanLisp.html>
You can run CLISP, which is freely available, on Win32 or Linux inside
Gnu Emacs, which represents one of the Better Environments in which to
use it. That may be pretty adequate to the "learning curve."
<http://clisp.cons.org/~haible/clisp.html>
On several Unixes like Linux, CMUCL <http://www.cons.org/cmucl/>
provides a _highly_ optimizing Lisp environment, also usable with Gnu
Emacs.
The Lisp vendors XAnalys and Franz both have "gratis" product
offerings for people wanting to "play around" with CL. URLs should be
obvious :-).
There are some other more "experimental" free options; the above are
the ones you'd most likely find worth looking at.
Skip GCL (Gnu Common Lisp); it predates the standardization of CL, and
is, on the one hand "fairly deviant," and on the other hand, not
terribly much maintained.
--
(concatenate 'string "cbbrowne" ·@" "acm.org")
<http://www.ntlug.org/~cbbrowne/linux.html>
Atheism is a non-prophet organization.
Thanks tremendously.
"Christopher Browne" <········@news.hex.net> wrote in message
································@test.sdt.com...
> In our last episode (Sun, 29 Oct 2000 21:07:08 -0600),
> the artist formerly known as Esteban said:
> >Thanks very much, everyone, for your generous responses to my questions.
> >I especially appreciate the links to Lisp tutorials.
> >I'll try to stop using all-ucase acronyms. Hard habit to break. (I
quite
> >smoking, though.)
>
> >Perhaps this is a bad question. What Lisp might one recommend for
> >the beginner? For 32-bit Windows NT/2000? For Linux? Are there
> >free or gnu ones that are adequate for learning Lisp programming?
>
> On Windows, one of the nicer "Windows-friendly" implementations is
> Corman Lisp.
> <http://www.corman.net/CormanLisp.html>
>
> You can run CLISP, which is freely available, on Win32 or Linux inside
> Gnu Emacs, which represents one of the Better Environments in which to
> use it. That may be pretty adequate to the "learning curve."
> <http://clisp.cons.org/~haible/clisp.html>
>
> On several Unixes like Linux, CMUCL <http://www.cons.org/cmucl/>
> provides a _highly_ optimizing Lisp environment, also usable with Gnu
> Emacs.
>
> The Lisp vendors XAnalys and Franz both have "gratis" product
> offerings for people wanting to "play around" with CL. URLs should be
> obvious :-).
>
> There are some other more "experimental" free options; the above are
> the ones you'd most likely find worth looking at.
>
> Skip GCL (Gnu Common Lisp); it predates the standardization of CL, and
> is, on the one hand "fairly deviant," and on the other hand, not
> terribly much maintained.
> --
> (concatenate 'string "cbbrowne" ·@" "acm.org")
> <http://www.ntlug.org/~cbbrowne/linux.html>
> Atheism is a non-prophet organization.
"Esteban" <····@catfish.net> writes:
> How might one rank LISP when viewing it in terms of the "high level"
> vs. "low level" continuum paradigm?
"A programming language is low level when its programs require
attention to the irrelevant." [Alan Perlis]
In this sense, I'd say that Lisp is "high level". However, when
typically "low level" issues _do_ become relevant, a decent Common
Lisp system will not stand in your way to deal with them. This I think
is one of the distinguishing features of Common Lisp.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@acm.org> writes:
> "Esteban" <····@catfish.net> writes:
>
> > How might one rank LISP when viewing it in terms of the "high level"
> > vs. "low level" continuum paradigm?
>
> "A programming language is low level when its programs require
> attention to the irrelevant." [Alan Perlis]
Outstanding quote. Summarizes what I'd been going to say much more succinctly.
> In this sense, I'd say that Lisp is "high level". However, when
> typically "low level" issues _do_ become relevant, a decent Common
> Lisp system will not stand in your way to deal with them. This I think
> is one of the distinguishing features of Common Lisp.
To this I would only add one thing, and that's the CL contains specific
capabilities (both a class system for data abstraction and a macro system
for syntactic abstraction) to promote the hiding of the irrelevant. One
of the things that makes me so down on Java is its lack of facility for
hiding the irrelevancies of syntax. Programs in Java invariably expose all
manner of detail they should not, and so Java by Perlis' excellent metric
above does not qualify as a high-level programming language. I regard Java
as a modern "assembly language". It provides power, but I want to call into
that power from the outside, or to use it as a back-end. I definitely don't
clamor to program directly in the language which is the source of that
power.
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> Frode Vatvedt Fjeld <······@acm.org> writes:
>
> > "Esteban" <····@catfish.net> writes:
> >
> > > How might one rank LISP when viewing it in terms of the "high level"
> > > vs. "low level" continuum paradigm?
> >
> > "A programming language is low level when its programs require
> > attention to the irrelevant." [Alan Perlis]
>
> Outstanding quote. Summarizes what I'd been going to say much more succinctly.
>
> > In this sense, I'd say that Lisp is "high level". However, when
> > typically "low level" issues _do_ become relevant, a decent Common
> > Lisp system will not stand in your way to deal with them. This I think
> > is one of the distinguishing features of Common Lisp.
>
> To this I would only add one thing, and that's the CL contains specific
> capabilities (both a class system for data abstraction and a macro system
> for syntactic abstraction) to promote the hiding of the irrelevant. One
> of the things that makes me so down on Java is its lack of facility for
> hiding the irrelevancies of syntax. Programs in Java invariably expose all
> manner of detail they should not, and so Java by Perlis' excellent metric
> above does not qualify as a high-level programming language. I regard Java
> as a modern "assembly language". It provides power, but I want to call into
> that power from the outside, or to use it as a back-end. I definitely don't
> clamor to program directly in the language which is the source of that
> power.
Procedural Macros for Java? Scary:
http://www.ai.mit.edu/projects/dynlangs/Talks/java-macros.htm
;-)
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
On Fri, 27 Oct 2000 09:46:02 GMT, Kent M Pitman <······@world.std.com>
wrote:
> Frode Vatvedt Fjeld <······@acm.org> writes:
[...]
> > "A programming language is low level when its programs require
> > attention to the irrelevant." [Alan Perlis]
>
> Outstanding quote. Summarizes what I'd been going to say much more succinctly.
This looks like a good place to attach the URL of the full list of Alan
Perlis' "Epigrams in Programming":
http://www.cs.yale.edu/~perlis-alan/quotes.html
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
On Thu, 26 Oct 2000 20:33:11 -0500, "Esteban" <····@catfish.net> wrote:
> (Pointers to good books (especially beginning treatises) on LISP
> programming, references, tutorials, web sites, etc. would be very greatly
You may start from here:
Association of Lisp Users
http://www.alu.org/
Basic Lisp Techniques
http://www.franz.com/resources/educational_resources/cooper.book.pdf
Common Lisp: A Gentle Introduction to Symbolic Computation
http://www.cs.cmu.edu:80/afs/cs.cmu.edu/user/dst/www/LispBook/index.html
Successful Lisp
http://psg.com/~dlamkins/left/sl/sl.html
> Is there an FAQ for this newsgroup?
Yes. You may get it at:
http://www.faqs.org/
ftp://rtfm.mit.edu/pub/usenet/comp.lang.lisp/
Note that although the FAQ is no longer being maintained, it is packed with
a lot of useful information and food for thought.
Have (de)fun,
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
I found Successful LISP at the following URL:
http://psg.com/~dlamkins/sl/sl.html
"Paolo Amoroso" <·······@mclink.it> wrote in message
·································@4ax.com...
> On Thu, 26 Oct 2000 20:33:11 -0500, "Esteban" <····@catfish.net> wrote:
>
> > (Pointers to good books (especially beginning treatises) on LISP
> > programming, references, tutorials, web sites, etc. would be very
greatly
>
> You may start from here:
>
> Association of Lisp Users
> http://www.alu.org/
>
> Basic Lisp Techniques
> http://www.franz.com/resources/educational_resources/cooper.book.pdf
>
> Common Lisp: A Gentle Introduction to Symbolic Computation
> http://www.cs.cmu.edu:80/afs/cs.cmu.edu/user/dst/www/LispBook/index.html
>
> Successful Lisp
> http://psg.com/~dlamkins/left/sl/sl.html
>
>
> > Is there an FAQ for this newsgroup?
>
> Yes. You may get it at:
>
> http://www.faqs.org/
> ftp://rtfm.mit.edu/pub/usenet/comp.lang.lisp/
>
> Note that although the FAQ is no longer being maintained, it is packed
with
> a lot of useful information and food for thought.
>
> Have (de)fun,
>
>
> Paolo
> --
> EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
> http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Christopher Browne wrote in message ...
>In our last episode (Tue, 24 Oct 2000 22:39:26 -0500),
>the artist formerly known as Esteban said:
>>Forgive an ignorant question:
>>
>>Is there an Object-Oriented version of LISP?
>
>Common Lisp was one of the first languages that was standardized with
>"Object Oriented" capabilities. The only other language that might brag
>of having OO earlier might be Ada.
>
Simula and Smalltalk certainly have earlier claim to O-O than
does Lisp. AFAIK, the first O-O implementation of Lisp was
done by Howard Cannon at MIT, c. 1978-1979; it was called
"Flavors", and was based on Smalltalk. It used a message-
passing paradigm.
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.
CLOS was based closely on New Flavors, and added multi-
methods and a true meta-object protocol. Gregor Kiczales,
as everyone knows, was one of the driving forces behind this.
In article <··················@typhoon.ne.mediaone.net>, "Scott McKay"
<···@mediaone.net> wrote:
> Christopher Browne wrote in message ...
> >In our last episode (Tue, 24 Oct 2000 22:39:26 -0500),
> >the artist formerly known as Esteban said:
> >>Forgive an ignorant question:
> >>
> >>Is there an Object-Oriented version of LISP?
> >
> >Common Lisp was one of the first languages that was standardized with
> >"Object Oriented" capabilities. The only other language that might brag
> >of having OO earlier might be Ada.
> >
>
>
> Simula and Smalltalk certainly have earlier claim to O-O than
> does Lisp.
Common Lisp had the first ANSI standard for an object-oriented
language. Ada had the first ISO standard, AFAIK.
> AFAIK, the first O-O implementation of Lisp was
> done by Howard Cannon at MIT, c. 1978-1979; it was called
> "Flavors", and was based on Smalltalk. It used a message-
> passing paradigm.
Other related influences:
- Frame Languages (based on the ideas of Marvin Minsky)
- Actors (based on the ideas of Carl Hewitt)
>
> 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.
>
> CLOS was based closely on New Flavors, and added multi-
> methods and a true meta-object protocol. Gregor Kiczales,
> as everyone knows, was one of the driving forces behind this.
LOOPS and later CommonLoops were influences for CLOS, too.
Here is a nice reference:
http://www.parc.xerox.com/istl/members/stefik/loops.html
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
>>> "SM" == Scott McKay <···@mediaone.net> writes:
SM> Simula and Smalltalk certainly have earlier claim to O-O
SM> than does Lisp.
How does Simula and CLOS compare? And which historical links are
there between the two? Is Simula alive in any sence?
-anders
Anders Vinjar wrote:
> How does Simula and CLOS compare? And which historical links are
> there between the two? Is Simula alive in any sence?
Some pointers to Simula information:
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.)
--
Martti Halminen <···············@solibri.com> wrote:
+---------------
| Some pointers to Simula information:
| http://www.iro.umontreal.ca/~simula/
| http://www.isima.fr/asu/
| http://home.sol.no/~simula/
+---------------
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
-----
Rob Warnock, 31-2-510 ····@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
[ Anders Vinjar ]
> How does Simula and CLOS compare? And which historical links are
> there between the two? Is Simula alive in any sence?
Simula was (sadly, IMO) switched for Java as beginner language a year
or two ago here at the Department for Informatics at the University of
Oslo, where the inventors of Simula, Ole-Johan Dahl and Kristen
Nygaard, still work -- now both as prof. emerituses. Since then the
language has rapidly gone out of use; I don't think it's used in any
course now.
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.
Martin
--
Unfortunately, the computer science departments in many universities
apparently believe that fluency in C++ is more important than a sound
education in elementary mathematics.
-Leslie Lamport, Specifying Concurrent Systems with TLA+
"Esteban" <····@catfish.net> writes:
> Forgive an ignorant question:
>
> Is there an Object-Oriented version of LISP?
>
>
One of them is CLOS aka Common Lisp Object System,
Which incorporates OO-thingies into Common-Lisp.
But you are free to to make it as "Object Orientated" as you wish
in your implementation or need.
cor
--
(defvar my-computer '((OS . "GNU Emacs") (Boot-Loader . "GNU Linux")))
/* If GNU/LINUX has no solution, you've got the wrong problem */
/* Never install Slackware.........You might learn to use IT */
/* ······@amsat.org http://clsnet.dynip.nl */