What does LISP stand for?
Christian Martin
We're debating around the office what LISP stands for, so I, being the
non-programmer, decided to find out. Can anyone pass along the answer?
Christian
Marco Antoniotti
In article <5tc95u$nl0$1...@client2.news.psi.net> "Christian Martin" <cma...@enactinc.com> writes:
Lots of Insipient and Stupid Parenthesis.
Lots of Inspired and Stupendous Programs.
Lists of Ingenious and Subtle Paraphrases.
LISt Processor.
You choose :)
--
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
William Paul Vrotney
In article <5tc95u$nl0$1...@client2.news.psi.net> "Christian Martin"
<cma...@enactinc.com> writes:
> We're debating around the office what LISP stands for, so I, being the
> non-programmer, decided to find out. Can anyone pass along the answer?
Lisp stands for "LISt Processing language" invented by John McCarthy at MIT
in the late 1950s. In Lisp the only two data types are the *list* and the
*atom*. The most important atom is a *symbol* which refers to some world
entity. The most important symbol is *nil* which refers to all of: false,
the empty list and the end of a list. Programs themselves are data made up
of lists and atoms nested in a specific kind of list called a *lambda*. In
actuality the fundamental data type is a dotted pair of which along with nil
lists are composed of. A dotted pair is implemented as a *cons* which
stands for "construct".
--
William P. Vrotney - vro...@netcom.com
Aaron Gross
vro...@netcom.com (William Paul Vrotney) writes:
> Lisp stands for "LISt Processing language" invented by John McCarthy at MIT
> in the late 1950s. In Lisp the only two data types are the *list* and the
> *atom*. The most important atom is a *symbol* which refers to some world
> entity. The most important symbol is *nil* which refers to all of: false,
> the empty list and the end of a list. Programs themselves are data made up
> of lists and atoms nested in a specific kind of list called a *lambda*. In
> actuality the fundamental data type is a dotted pair of which along with nil
> lists are composed of. A dotted pair is implemented as a *cons* which
> stands for "construct".
Hey, you got the first sentence right!
Martin Rodgers
Marco Antoniotti wheezed these wise words:
> Lots of Insipient and Stupid Parenthesis.
> Lots of Inspired and Stupendous Programs.
> Lists of Ingenious and Subtle Paraphrases.
> LISt Processor.
>
> You choose :)
I'll pick "Lisp In Small Pieces". ;) The book _and_ the language.
--
"As you read this: Am I dead yet?" - Rudy Rucker
Please note: my email address is gubbish
Marco Antoniotti
In article <MPG.e6403daf...@news.demon.co.uk> mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
Newsgroups: comp.lang.lisp
Date: Wed, 20 Aug 1997 07:05:32 +0100
Organization: The Wildcard Killer Butterfly Breeding Ground
NNTP-Posting-Host: wildcard.demon.co.uk
X-NNTP-Posting-Host: wildcard.demon.co.uk [158.152.30.20]
X-Newsreader: Anawave Gravity v1.10.575
Lines: 13
Marco Antoniotti wheezed these wise words:
> Lots of Insipient and Stupid Parenthesis.
> Lots of Inspired and Stupendous Programs.
> Lists of Ingenious and Subtle Paraphrases.
> LISt Processor.
>
> You choose :)
I'll pick "Lisp In Small Pieces". ;) The book _and_ the language.
I saw the book. Looks good, but it is not "for the masses".
Denotational Semantics and friends don't quite cut it :)
I am really waiting for a "Common Lisp in a Nutshell". :)
William Paul Vrotney
In article <joswig-ya0231800...@news.lavielle.com>
jos...@lavielle.com (Rainer Joswig) writes:
>
> In article <vrotneyE...@netcom.com>, vro...@netcom.com (William Paul
> Vrotney) wrote:
>
> > I suspect your confusion comes about by thinking in terms of a specific
> > Lisp. For example in Common Lisp every object is of type T. The two major
> > subtypes of T are LIST and ATOM (or more precisely CONS and ATOM). So this
> > was true in the 50s and still true today. For example
> >
> > (atom (make-array 10)) => T
>
> Old thinking. ;-)
No this is not old thinking, it is exactly true of Common Lisp today.
Please study the Common Lisp literature.
>
> Common Lisp has a hierarchy of types.
>
The Common Lisp hierarchy falls under only two super types, ATOM and LIST.
But that is besides the point. The original question was about Lisp not
Common Lisp. How many times in this newsgroup do we have to point out that
there is a difference? A Lisp with *only* two terminal types, symbol (an
atom) and cons (a list), and *no* other hierarchy is still a legitimate
and important Lisp.
Unfortunately in Interlisp the meaning of ATOM was not this distinctive.
> (type-of 3) -> fixnum
> (type-of (find-class 'standard-class)) -> standard-class
>
> Both of the above are also atoms.
Confirming what I said above.
>
> The distinction between CONS and ATOM is in newer Lisp systems
> relatively meaningless.
Baloney.
> The function ATOM is true when something is not a
> CONS.
And you refer to this as relatively meaningless? Is FALSE relatively
meaningless because when something is TRUE it is not FALSE?
> On a Lisp machine this may be hundred types and thousands
> of classes.
>
Yes and (assuming that you are not talking about an Interlisp machine) all
of these types and classes except for CONS types are of type ATOM. The
distinction between a list and an atom is more than you make it out to be.
It was in the 50s and still is today. Lisp has not changed in this respect.
In fact the emphasis on lists as contrasted with atoms and that lists and
some atoms are and must be *primitive* types in Lisp is why we call Lisp
LISP, which answers the original question of this thread.
Erik Naggum
* William Paul Vrotney -> Rainer Joswig
| Please study the Common Lisp literature.
| The Common Lisp hierarchy falls under only two super types, ATOM and
| LIST.
this is getting to the point of being embarrassingly ridiculous. you're
mistaken, and that's it. if you think you are not mistaken, stop repeating
yourself and start quoting the ANSI standard to support your position.
| The original question was about Lisp not Common Lisp.
the original question was "what does LISP stand for". why do you insist on
answering a totally different question? "LISP" stands for exactly the same
in _your_ favorite Lisp as in Common Lisp. get a grip.
| How many times in this newsgroup do we have to point out that there is a
| difference?
"have to"? "we"? _zero_ would be a good number.
| > (type-of 3) -> fixnum
| > (type-of (find-class 'standard-class)) -> standard-class
| >
| > Both of the above are also atoms.
|
| Confirming what I said above.
look, you aren't this stupid. get off the prestige and realize that what
you said is in fact _untrue_, namely that Common Lisp has "atom" and "list"
as an exhaustive partioning of its types. note that the () is both an atom
and a list, so they aren't mutually exclusive in the first place, but let's
pretend you meant "cons" instead of "list". `atom' as a type specifier is
_identical_ to (not cons), causing your claim to become the meaningless
tautology: "Lisp is exhaustively partitioned into the types `cons' and `not
cons'." why you keep harping on this is beyond me.
relax, cut the need to maintain your prestige, and admit your mistakes.
you can't save face by _not_ admitting this mistake, but you _can_ save
face if you stop repeating these mistaken beliefs about what Common Lisp
does and just say "sorry". it's clear that you don't like Common Lisp, but
I suggest you make an effort to learn it before you keep embarrassing
yourself more. visiting http://www.harlequin.com/books/HyperSpec/ is a
good start. Guy Steele's Common Lisp the Language, 2nd edition, is another
good start. you will find that `atom' is _not_ a fundamental type.
#\Erik
--
man who cooks while hacking eats food that has died twice.
Rainer Joswig
In article <scf7mdg...@infiniti.PATH.Berkeley.EDU>,
mar...@infiniti.PATH.Berkeley.EDU (Marco Antoniotti) wrote:
> In article <MPG.e6403daf...@news.demon.co.uk>
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) writes:
>
> Newsgroups: comp.lang.lisp
> Date: Wed, 20 Aug 1997 07:05:32 +0100
> Organization: The Wildcard Killer Butterfly Breeding Ground
> NNTP-Posting-Host: wildcard.demon.co.uk
> X-NNTP-Posting-Host: wildcard.demon.co.uk [158.152.30.20]
> X-Newsreader: Anawave Gravity v1.10.575
> Lines: 13
>
> Marco Antoniotti wheezed these wise words:
>
> > Lots of Insipient and Stupid Parenthesis.
> > Lots of Inspired and Stupendous Programs.
> > Lists of Ingenious and Subtle Paraphrases.
> > LISt Processor.
> >
> > You choose :)
>
> I'll pick "Lisp In Small Pieces". ;) The book _and_ the language.
Lisp is simply perfect.
Erik Naggum
* William Paul Vrotney
| You are wrong. The whole thing is correct.
the whole thing is a pathetic excuse for an explanation, _very_ confused.
| The person asking the question said he is not a programmer and did not ask
| the question about a specific Lisp so I did not want to go into specific
| Lisps and their subtypes.
he asked what "LISP" stood for, and that's all he asked. your first
sentence was correct and to the point, the rest was nowhere near requested,
and confusing to boot. please spare us the defense of your mistake.
| I suspect your confusion comes about by thinking in terms of a specific
| Lisp.
that others should think in terms of a specific Lisp seems to be a pet
peeve among some who think they are defending Lisp. I don't understand the
need to be _incorrect_ in addition to _unspecific_ about what Lisp is, but
it's typical of those who do that they are seriously confused about any and
all Lisps that they try to encompass with their definitions. moreover, it
does _nothing_ to help spread the word of Lisp that some insist on talking
about "vintage Lisp" and hanging on to age-old confusions just because they
don't like Common Lisp.
it _would_ be constructive to say that the Lisp family has two main
branches in modern incarnations: Common Lisp and Scheme, if there is a need
to defend both, but whoever would want to defend, e.g., Emacs Lisp as the
language of choice when talking about Lisp?
| For example in Common Lisp every object is of type T. The two major
| subtypes of T are LIST and ATOM (or more precisely CONS and ATOM).
this is incorrect. the type `atom' is just another name for (not cons),
and `atom' is thus _not_ a system class. the class precedence list of
`cons' is (cons list sequence t). this should give an idea of how far off
the mark you are, so just can it, OK?
William Paul Vrotney
In article <lylo1xv...@morannon.bfr.co.il> Aaron Gross
<aa...@morannon.bfr.co.il> writes:
You are wrong. The whole thing is correct.
The person asking the question said he is not a programmer and did not ask
the question about a specific Lisp so I did not want to go into specific
Lisps and their subtypes. I wanted to explain in simple terms why Lisp was
called LISP. Perhaps I should have said "In Lisp every object is either a
*list* or an *atom*". But I wanted to stress that it is sufficient to have
*only* two types to qualify as a Lisp in general and hence its name. I hope
you understand that a Lisp with *only* lists and symbols was and still is a
legitimate Lisp and an important computational model. All the rest about
symbols and lambda is also correct.
I suspect your confusion comes about by thinking in terms of a specific
Lisp. For example in Common Lisp every object is of type T. The two major
subtypes of T are LIST and ATOM (or more precisely CONS and ATOM). So this
was true in the 50s and still true today. For example
(atom (make-array 10)) => T
Rainer Joswig
> I suspect your confusion comes about by thinking in terms of a specific
> Lisp. For example in Common Lisp every object is of type T. The two major
> subtypes of T are LIST and ATOM (or more precisely CONS and ATOM). So this
> was true in the 50s and still true today. For example
>
> (atom (make-array 10)) => T
Old thinking. ;-)
Common Lisp has a hierarchy of types.
(type-of 3) -> fixnum
(type-of (find-class 'standard-class)) -> standard-class
Both of the above are also atoms.
The distinction between CONS and ATOM is in newer Lisp systems
relatively meaningless. The function ATOM is true when something is not a
CONS. On a Lisp machine this may be hundred types and thousands
of classes.
Martin Rodgers
Marco Antoniotti wheezed these wise words:
> I saw the book. Looks good, but it is not "for the masses".
> Denotational Semantics and friends don't quite cut it :)
I agree, but I like that kind of compiler theory. I'm finally starting
to feel comfortable with Combinatory Logic. Is this a bad sign?
> I am really waiting for a "Common Lisp in a Nutshell". :)
So am I! Alas, I don't think I'm the right person to write it, or I'd
have approached ORA with the idea some time ago. I'm "new" enough to
Lisp to see it from the outside, but I learned Lisp by reading
tutorials and reference books, and then writing Lisp interpreters. Not
exactly a typical way to do it, I think.
On the other hand, I'll be more than happy to proof read such a book.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Rainer Joswig
> > Old thinking. ;-)
>
> No this is not old thinking, it is exactly true of Common Lisp today.
> Please study the Common Lisp literature.
Of course it is true still today. Either you have a cons or not (an atom
that is).
How about following partitions:
array or not
number or not
class or not
structure or not
> > Common Lisp has a hierarchy of types.
> >
>
> The Common Lisp hierarchy falls under only two super types, ATOM and LIST.
Oops.
(subtypep 'array 'atom) even don't cares to deliver true.
> But that is besides the point. The original question was about Lisp not
> Common Lisp.
Scheme is no different. Same is true for EuLisp.
> there is a difference? A Lisp with *only* two terminal types, symbol (an
> atom) and cons (a list), and *no* other hierarchy is still a legitimate
> and important Lisp.
It may be as useful as pure Lambda Calculus. Most real Lisp systems
have a multitude of datatypes and they are not implemented with
lists. Once you are using lists, the distintion between cons
and atom is useful. If you are using structures, class, arrays,
hashtables, conditions, vectors, strings, ... it is not.
> Unfortunately in Interlisp the meaning of ATOM was not this distinctive.
CLtL2 says in InterLisp there are only symbols and number considered
to be atoms. Arrays and strings are not atoms and not conses.
>
> > (type-of 3) -> fixnum
> > (type-of (find-class 'standard-class)) -> standard-class
> >
> > Both of the above are also atoms.
>
> Confirming what I said above.
Which makes the distinction useless while dealing with classes.
> > The distinction between CONS and ATOM is in newer Lisp systems
> > relatively meaningless.
>
> Baloney.
In pure Scheme you may have to use lists (you could use
closures) to implement datastructures. In Common Lisp
you can add user defined types. When using them, you
don't need the function "atom" or the type atom.
> > The function ATOM is true when something is not a
> > CONS.
>
> And you refer to this as relatively meaningless? Is FALSE relatively
> meaningless because when something is TRUE it is not FALSE?
TRUE and FALSE are two single entities. CONS is a type specifier
which stands for one type - a cons cell. ATOM stands for the
others five thousand ;-) direct (those not consisting
of OR, AND, NOT combinations) types .
> It was in the 50s and still is today. Lisp has not changed in this respect.
> In fact the emphasis on lists as contrasted with atoms and that lists and
> some atoms are and must be *primitive* types in Lisp is why we call Lisp
> LISP, which answers the original question of this thread.
With a modern Lisp, classes are the most important building blocks (IMHO).
Some vendors tried to put emphasize on this by selling "CLOS"
and not "Common Lisp".
Btw., I'm using "ANSI Common Lisp", not "CLOS". ;-)
While "Lisp" stands for "List processing", it would be misleading
to tell people Lisp *is* still "List processing". It is not. People
I talk to believe those old thinking: "In Lisp everything is a list".
I had to tell him that this may not be true since some years. ;-)
Same mistake: Lisp is a functional programming language. It
is not.
Greetings,
Rainer Joswig
William Paul Vrotney
In article <30810814...@naggum.no> Erik Naggum <cle...@naggum.no>
writes:
>
> * William Paul Vrotney -> Rainer Joswig
> | Please study the Common Lisp literature.
> :
> | The Common Lisp hierarchy falls under only two super types, ATOM and
> | LIST.
>
> this is getting to the point of being embarrassingly ridiculous. you're
> mistaken, and that's it. if you think you are not mistaken, stop repeating
> yourself and start quoting the ANSI standard to support your position.
>
No I am not mistaken. You can prove me wrong by creating a Common Lisp
object *object* that returns NIL for
(or (subtypep *object* 'atom) (subtypep *object* 'list))
See http://www.harlequin.com/education/books/HyperSpec/Body/typ_atom.html
for a description of type ATOM. And see
http://www.harlequin.com/education/books/HyperSpec/Body/syscla_list.html for
a description of type LIST.
> | The original question was about Lisp not Common Lisp.
>
> the original question was "what does LISP stand for". why do you insist on
> answering a totally different question? "LISP" stands for exactly the same
> in _your_ favorite Lisp as in Common Lisp. get a grip.
>
Pay attention! I did answer the original question as to what LISP stands
for. I just added the additional stuff about lists and atoms to give the
person asking the question the complete story behind the name LISP. The
partitioning of Lisp space into list space and atom space is an important
part of this story.
For some reason that fact that I reminded us that the concept of type ATOM
is still around in Common Lisp seems to bother you and a few others.
> | How many times in this newsgroup do we have to point out that there is a
> | difference?
>
> "have to"? "we"? _zero_ would be a good number.
>
Several people have emphasized in this newsgroup for years that to be
precise it is important to have mutual understanding that there is a
difference between Lisp in general and a specific Lisp such as Common Lisp.
> | > (type-of 3) -> fixnum
> | > (type-of (find-class 'standard-class)) -> standard-class
> | >
> | > Both of the above are also atoms.
> |
> | Confirming what I said above.
>
> look, you aren't this stupid. get off the prestige and realize that what
> you said is in fact _untrue_, namely that Common Lisp has "atom" and "list"
> as an exhaustive partioning of its types. note that the () is both an atom
> and a list, so they aren't mutually exclusive in the first place, but let's
> pretend you meant "cons" instead of "list". `atom' as a type specifier is
Well, to be precise (in Common Lisp for example) we actually mean type LIST
since LIST is a more super type than cons:
(subtypep 'cons 'list) => T
(subtypep 'nil 'list) => T
Also the fact that NIL is both an atom and a list does not effect an
exhaustive covering of types. Also note that
(subtypep 'atom 'atom) => T
(subtypep 'list 'sequence) => T
but the type SEQUENCE is intended for the grouping of lists and ATOMs that
behave like sequences, one dimensional arrays in particular, with the intent
of creating operations that operate on both.
> _identical_ to (not cons), causing your claim to become the meaningless
> tautology: "Lisp is exhaustively partitioned into the types `cons' and `not
> cons'." why you keep harping on this is beyond me.
>
I am not harping on this I am only defending my explaination of why Lisp was
called LISP and why lists and atoms were and still are important concepts in
Lisp. Thats all I was trying to say!
But I am not sure what you are trying to say. Are you trying to say that
types LIST and ATOM is *not* an exhaustive covering of all Common Lisp
types? Are you trying to say that the notion of ATOM is not important in
Common Lisp? Are you trying to say that the type ATOM and function ATOM are
not necessary? Please be more specific.
> relax, cut the need to maintain your prestige, and admit your mistakes.
> you can't save face by _not_ admitting this mistake, but you _can_ save
> face if you stop repeating these mistaken beliefs about what Common Lisp
> does and just say "sorry". it's clear that you don't like Common Lisp,
No it is not clear. I like Common Lisp, it is my language of choice and I
have programmed in it for years. I will gladly admit a mistake if it is one
but you haven't proved that. By the way, what exactly is the mistake you
are referring to?
> but
> I suggest you make an effort to learn it before you keep embarrassing
> yourself more. visiting http://www.harlequin.com/books/HyperSpec/ is a
> good start. Guy Steele's Common Lisp the Language, 2nd edition, is another
> good start. you will find that `atom' is _not_ a fundamental type.
>
I have a lot of experience programming in Common Lisp and have visted both
of these documents many times.
Pay attention. I said that "lists and *some* atoms must be *primitive*
types". For example in Common Lisp how could
(defun faa (x) (+ x x))
containing both lists and symbols (atoms) be evaluated primitively
otherwise?
Contained in my original answer to the question of "what LISP stands for" I
had the sentences
"In Lisp the only two data types are the *list* and the *atom*. The most
important atom is a *symbol* which refers to some world entity."
which caused some to think that Lisp had only two data types (which in
actuality it does at a high level). Perhaps I should have said
"In Lisps in general at a high level the only two data types are the *list*
and the *atom*. The most important atom is a *symbol* which refers to some
world entity."
Note that the *only* is important here for someone trying to understand why
Lisp is called LISP for "LISt Processing language". That is to say the
importance of the list and atom dichotomy and that s-expressions are
defined in terms of lists and atoms.
William Paul Vrotney
In article <vrotneyE...@netcom.com> vro...@netcom.com (William Paul
Vrotney) writes:
>
>
> In article <30810814...@naggum.no> Erik Naggum <cle...@naggum.no>
> writes:
>
> >
> > * William Paul Vrotney -> Rainer Joswig
> > | Please study the Common Lisp literature.
> > :
> > | The Common Lisp hierarchy falls under only two super types, ATOM and
> > | LIST.
> >
> > this is getting to the point of being embarrassingly ridiculous. you're
> > mistaken, and that's it. if you think you are not mistaken, stop repeating
> > yourself and start quoting the ANSI standard to support your position.
> >
>
> No I am not mistaken. You can prove me wrong by creating a Common Lisp
> object *object* that returns NIL for
>
> (or (subtypep *object* 'atom) (subtypep *object* 'list))
>
> See http://www.harlequin.com/education/books/HyperSpec/Body/typ_atom.html
> for a description of type ATOM. And see
> http://www.harlequin.com/education/books/HyperSpec/Body/syscla_list.html for
> a description of type LIST.
>
Oops ... that should have been
(or (subtypep (type-of *object*) 'atom)
(subtypep (type-of *object*) 'list)))
Isn't it ironic that Erik claims that just about everything I said was wrong
but one thing that I said that is obviously wrong he missed. :-)
Erik Naggum
* William Paul Vrotney
| No I am not mistaken. ...
| Pay attention! ...
| For some reason that fact that I reminded us that the concept of type ATOM
| is still around in Common Lisp seems to bother you and a few others.
no, what bothers me, at least, is that you pretend that some distinction is
fundamental when it is not. this is your mistake. and, I might add, it's
getting ludicrous when you scream "pay attention" to others here, when you
so clearly don't do it yourself. we're not debating this in comp.lang.c++.
| I am not harping on this I am only defending my explaination of why Lisp
| was called LISP and why lists and atoms were and still are important
| concepts in Lisp. Thats all I was trying to say!
it's too much and too little at the same time. you were talking about
lists, but I think you were grappling at the symbolic expression and trying
to say something about lists. clearly, you're confused beyond reach, but
if you had confined yourself to tell the poor requestor that the "list" in
LISt Processing refers to the list of the symbolic expression, we might be
getting somewhere. but that is not what you said.
| But I am not sure what you are trying to say.
I'm refuting your claim. I'm pointing out to you that it is false. I'm
showing you where your claim falls apart. I'm debunking yet another myth.
I'm saying that you should have stopped after the first sentence. that's
what I'm trying to say. may I suggest that a "pay attention" is in order?
| Are you trying to say that types LIST and ATOM is *not* an exhaustive
| covering of all Common Lisp types? Are you trying to say that the notion
| of ATOM is not important in Common Lisp? Are you trying to say that the
| type ATOM and function ATOM are not necessary? Please be more specific.
when somebody is refuting some claim, that doesn't mean that they are
thereby _claiming_ whatever bogus opposites of the refuted claim somebody
may conjure up. I consider the tendency among some people to react to a
"no, that's not true" by hurling accusations back that everything they hold
as dear and obvious truths and that they consider to follow from whatever
it is they believe is _also_ contradicted in a single negation of a single
proposition to be quite astonishingly anti-intellectual.
in particular, I'm not at all interested in what you have built on top of
your confused understanding of LIST and ATOM, nor am I interested in
answering any of your stupid questions -- that would serve only to take
this discussion even further off track. I think it's indicative of your
serious confusion that you feel the need to ask them. you are no longer
defending a view of Lisp, you are defending yourself, and doing it badly.
| By the way, what exactly is the mistake you are referring to?
that the Common Lisp type system is _fundamentally_ partitioned into the
two _types_ LIST and ATOM. it isn't. from what I can see from LISP 1.5
Programmer's Manual, your claim wasn't even true in 1962.
[lots of bogosity deleted to save space and time.]
| Perhaps I should have said
|
| "In Lisps in general at a high level the only two data types are the
| *list* and the *atom*. The most important atom is a *symbol* which
| refers to some world entity."
it is _still_ wrong. what you could have said was something like:
Lists in Lisp consist of objects of various types, including lists.
but this is no more _worth_ saying than
Arrays in Lisp consist of objects of various types, including arrays.
etc for _all_ the container types in Lisp. there's nothing "high level"
about talking about the list as if it were fundamentally important for the
type system.
however, the list _is_ fundamentally important to the s-expression, and
what I think you're grabbing at, but can't reach in your confused state,
is something along the lines of the following shot from the hip:
In Lisp, the fundamental programming concept is the `symbolic
expression', or `s-expression' for short. A s-expression is either an
atom or a list of s-expressions. An object of any type except list is
called an `atom'. A list whose the first atom is a symbol is called a
form, and that symbol defines the meaning of the whole form. A Lisp
program is made up of many, nested forms. The Lisp type system has a
large number of types in addition to symbols and lists, both atomic and
containers, including numbers of many types, vectors, arrays, and
strings, all of which form a type hierarchy. Lisp has functions that
work on objects at any level of this hierarchy. Despite the importance
of the list for s-expressions, modern Lisp programs use lists sparingly
at run-time. The s-expression is a convenient way to represent code
(functions) as objects in the language itself. It follows that most
types can be represented in text form and that they can be printed from
a Lisp system. This is often referred to as "code and data are
interchangable in Lisp", but this applies to the uncompiled form of the
code, only. Lisp is naturally a compiled language, even though it also
follows from the above that it is easy to write an interpreter. Toy
Lisps are frequently interpreted-only. Unfortunately, most beginners
only play with the toy Lisps -- many a myth has thus been perpetuated.
*whew* stuffing Lisp into a small box is damn hard work.
William Paul Vrotney
In article <joswig-ya0231800...@news.lavielle.com>
jos...@lavielle.com (Rainer Joswig) writes:
> > > Common Lisp has a hierarchy of types.
> > >
> >
> > The Common Lisp hierarchy falls under only two super types, ATOM and LIST.
>
> Oops.
>
> (subtypep 'array 'atom) even don't cares to deliver true.
>
>
Hm ..., on my Lisps I get
(subtypep 'array 'atom) => T ; Franz Allegro
(subtypep 'array 'atom) => T ; GCL
(subtypep 'array 'atom) => NIL NIL ; Clisp
(atom (make-array 10)) => T ; Clisp
Did your CL return NIL T or NIL NIL (note second return value)? It is
important, the two have different meanings. If it returned NIL NIL then
ARRAY is still a subtype of ATOM, *subtypep* just couldn't compute it in
this situation.
In CLTL II on page 97 it says
"If the result of *subtypep* is *nil*, however then *type1* may or may not
be a subtype of *type2* (sometimes it is impossible to tell, especially when
_satisfies_ type specifiers are involved."
In any case I guess I am forced to change the covering proof (mentioned in a
previous post) to
(or (listp x) (atom x))
Thanks for the input.
Rainer Joswig
> Hm ..., on my Lisps I get
>
> (subtypep 'array 'atom) => T ; Franz Allegro
> (subtypep 'array 'atom) => T ; GCL
> (subtypep 'array 'atom) => NIL NIL ; Clisp
> (atom (make-array 10)) => T ; Clisp
>
> Did your CL return NIL T or NIL NIL (note second return value)? It is
> important, the two have different meanings. If it returned NIL NIL then
> ARRAY is still a subtype of ATOM,
Both MCL and Symbolics CL are giving me NIL NIL.
> *subtypep* just couldn't compute it in
> this situation.
Yes!
Rainer Joswig
In article <33FCE649...@ilog.com>, Harley Davis <da...@ilog.com> wrote:
> Erik Naggum wrote:
>
> > | For example in Common Lisp every object is of type T. The two major
> >
> > | subtypes of T are LIST and ATOM (or more precisely CONS and ATOM).
> >
> > this is incorrect. the type `atom' is just another name for (not
> > cons),
> > and `atom' is thus _not_ a system class. the class precedence list of
> >
> > `cons' is (cons list sequence t). this should give an idea of how far
> > off
> > the mark you are, so just can it, OK?
> >
>
> Erik, the fact that you think that "types" and "classes" are the same
> thing in Common Lisp shows how far off the mark *you* are.
(type-of <anything>)
will never return ATOM, in a sane implementation of a more modern Lisp,
may it be ANSI Common Lisp.
Andreas Eder
William Paul Vrotney wrote:
>No I am not mistaken. You can prove me wrong by creating a Common Lisp
>object *object* that returns NIL for
>
> (or (subtypep *object* 'atom) (subtypep *object* 'list))
Let me rewrite this as:
(or (atom *object*) (listp *object*))
now if you look into the HyperSpec you see that atom is (not cons), and a list
is either a cons or null, so this gives:
(or (not (consp *object*)) (or (consp *object*) (null *object*)))
which by the associativity of or gives:
(or (or (not (consp *object*)) (consp *object*)) (null *object*))
which is easily seen to be
(or t (null *object*)) --> t
so, this was a tautology, and we can say that everything is either a list or
an atom.
But, for someone who didn't even know where the name Lisp comes from, this may
be very misleading; he might think that Lisp do not even offer numbers, or
arrays, or structures. You get the point?
So, you were right technically, but wwrong pedagogically.
Andreas
Martin Rodgers
Rainer Joswig wheezed these wise words:
> Both MCL and Symbolics CL are giving me NIL NIL.
FWIW, LispWorks gives me:
CL-USER 1 > (subtypep 'array 'atom)
T
T
Not that I'm interested in this thread in any way. ;) I just couldn't
resist trying it in LispWorks...
William Paul Vrotney
In article <joswig-ya0231800...@news.lavielle.com>
jos...@lavielle.com (Rainer Joswig) writes:
>
> In article <vrotneyE...@netcom.com>, vro...@netcom.com (William Paul
> Vrotney) wrote:
>
> > In any case I guess I am forced to change the covering proof (mentioned in a
> > previous post) to
> >
> > (or (listp x) (atom x))
>
> ? (atom nil)
> T
> ? (consp nil)
> NIL
> ? (listp nil)
> T
>
Yeah so what?
(or (listp nil) (atom nil)) => T
William Paul Vrotney
In article <MPG.e67b2fd4...@news.demon.co.uk>
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) writes:
>
> Rainer Joswig wheezed these wise words:
>
> > Both MCL and Symbolics CL are giving me NIL NIL.
>
> FWIW, LispWorks gives me:
>
> CL-USER 1 > (subtypep 'array 'atom)
> T
> T
>
> Not that I'm interested in this thread in any way. ;) I just couldn't
> resist trying it in LispWorks...
Hey, I am not interested in this thread either, never was. My only interest
was my original answer to the derivation of "LISP" question. However when
people made claims that I was wrong I had to defend. They could have added
additional statements or clarifications but instead this this ATOM aversion
surfaced.
Martin Rodgers
Erik Naggum wheezed these wise words:
> I'll just note that some people will always believe that others are opposed
> to their conclusions regardless of how well or how much they have argued
> against their premises or their reasoning.
This is true. I call it "redmisting", as if a redmist forms before
their eyes, blinding them to what other people are really saying.
You can agree with people, and even say so, and they still flame you.
William Paul Vrotney
In article <30814281...@naggum.no> Erik Naggum <cle...@naggum.no>
writes:
>
> * William Paul Vrotney
> | ... but instead this this ATOM aversion surfaced.
>
> the "aversion" was not to ATOM or to ATOM vs LIST. the aversion was to
> making that artificial distinction appear fundamental to the type system.
>
Well then, if you are being intellectually honest, you would have an
aversion to multitudes of Lisp data in the form of Lisp s-expressions which
are fundamentally defined in terms of ATOMs and LISTs. This is fundamental
stuff in text books.
If you are being intellectually honest you would have an aversion to
(if (consp x) ...)
being a frequent and fundamentally important object type branch in
multitudes of Lisp code.
> I'll just note that some people will always believe that others are opposed
> to their conclusions regardless of how well or how much they have argued
> against their premises or their reasoning.
>
Erik, I don't believe that you have been opposed to my conclusions. I
believe that you have been opposed to most everyone's conclusions. However,
I think that you are a bright guy who has a lot to offer.