Hi,
My only use for lisp at the moment is for xemacs, but
I have a very basic question that's making me very
uncomfortable. I've also got Winston, Klaus, and
Horn's "LISP" (3rd ed) which I have read perhaps
25 percent of.
There is a command in xemacs called "packages-find-package-data-path"
that takes as an argument a list of package directories:
`packages-find-package-data-path' (buffer: *Hyper Apropos*, mode: Hyper-Apropos)
Compiled Lisp function,
(loaded from "/apps/public/XEmacs/src/xemacs-21.4.10/build-motif/lisp/packages.elc"):
arguments: (packages)
Construct the data-path component for packages.
PACKAGES is a list of package directories.
BUT..., it doesn't take just any ole' list - it MUST have a list of
STRINGS. For example, this doesn't work:
(packages-find-package-data-path '(/dir))
I get a "Wrong argument: sequencep, /dir" error.
However, if I use a string for the list elements
everything is fine:
(packages-find-package-data-path '("/dir"))
returns "nil".
So my problem is this: After reading the Winston text,
it appeared that the members of a list are some sort
of typeless things. For example, the command
(setq friends '(bush cheney))
works just fine, but what are the data types of the
elements "bush" and "cheney"? Going back to the
xemacs command what type is the list (/dir) if it's
not a string? Can a list element have any type? If
not, what subset of types may they assume?
Help! I'm lost in basic questions!
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
···········@sonyericsson.com, 919-472-1124
Randy Yates wrote:
> (packages-find-package-data-path '("/dir"))
>
> returns "nil".
>
> So my problem is this: After reading the Winston text,
> it appeared that the members of a list are some sort
> of typeless things. For example, the command
>
> (setq friends '(bush cheney))
>
> works just fine, but what are the data types of the
> elements "bush" and "cheney"?
In this case, symbol. Symbols are severely different between different
LISPs, so don't bother trying to understand it right now. Instead, read on.
> Going back to the
> xemacs command what type is the list (/dir) if it's
> not a string? Can a list element have any type? If
> not, what subset of types may they assume?
>
Unless otherwise declared, a list element can have any type, including other
lists. That's also an easy way to make trees, by the way.
> Help! I'm lost in basic questions!
You're also lost in basic LISPs; the implementation of LISP used in Emacs
diverged (and stagnated) well over a decade ago.
To avoid further confusion: This newsgroup concerns Lisp, a common
contraction of Common Lisp, which is by far the most advanced member of the
family.
Take a look at these two links for more details:
Setup guide: http://www.unmutual.info/startingwithcl.html
CL tutorial/book: http://www.gigamonkeys.com/book/
In article <············@services.kq.no>,
Svein Ove Aas <·········@aas.no> wrote:
> Randy Yates wrote:
>
> > (packages-find-package-data-path '("/dir"))
> >
> > returns "nil".
> >
> > So my problem is this: After reading the Winston text,
> > it appeared that the members of a list are some sort
> > of typeless things. For example, the command
> >
> > (setq friends '(bush cheney))
> >
> > works just fine, but what are the data types of the
> > elements "bush" and "cheney"?
>
> In this case, symbol. Symbols are severely different between different
> LISPs, so don't bother trying to understand it right now. Instead, read on.
>
> > Going back to the
> > xemacs command what type is the list (/dir) if it's
> > not a string? Can a list element have any type? If
> > not, what subset of types may they assume?
> >
> Unless otherwise declared, a list element can have any type, including other
> lists. That's also an easy way to make trees, by the way.
>
> > Help! I'm lost in basic questions!
>
> You're also lost in basic LISPs; the implementation of LISP used in Emacs
> diverged (and stagnated) well over a decade ago.
>
> To avoid further confusion: This newsgroup concerns Lisp, a common
> contraction of Common Lisp, which is by far the most advanced member of the
> family.
If there isn't a more specific newsgroup, I'm happy to read
here about other Lisps as well.
Randy Yates <···········@sonyericsson.com> writes:
> (setq friends '(bush cheney))
>
> works just fine, but what are the data types of the
> elements "bush" and "cheney"? Going back to the
> xemacs command what type is the list (/dir) if it's
> not a string? Can a list element have any type? If
> not, what subset of types may they assume?
You can use the emacs-lisp function: type-of
to learn what the type of a value is.
For example, type in the *scratch* buffer:
(type-of 'bush) C-x C-e
and see what appears on the mini-buffer, or:
(type-of 'bush) C-u C-x C-e
and see what is inserted at the point.
(setq friends '(bush cheney)) C-x C-e
(type-of friends) C-u C-x C-e
(type-of (car friends)) C-u C-x C-e
> Help! I'm lost in basic questions!
As Svein indicated, the lisp in emacs/xemacs is not the lisp we
usually discuss here, Common-Lisp. You can get better help with
emacs-lisp on:
news:gnu.emacs.help
news:comp.emacs
news:comp.emacs.xemacs
--
__Pascal Bourguignon__
Randy Yates wrote:
> My only use for lisp at the moment is for xemacs,
There are some emacs-related Usenet groups where you
might get a more focused answer. However ...
> BUT..., it doesn't take just any ole' list - it MUST have a list of
> STRINGS. For example, this doesn't work:
>
> (packages-find-package-data-path '(/dir))
>
> I get a "Wrong argument: sequencep, /dir" error.
> However, if I use a string for the list elements
> everything is fine:
>
> (packages-find-package-data-path '("/dir"))
>
> returns "nil".
>
> So my problem is this: After reading the Winston text,
> it appeared that the members of a list are some sort
> of typeless things. For example, the command
>
> (setq friends '(bush cheney))
>
> works just fine, but what are the data types of the
> elements "bush" and "cheney"? Going back to the
> xemacs command what type is the list (/dir) if it's
> not a string? Can a list element have any type? If
> not, what subset of types may they assume?
The elements of a list can have any type(s).
That doesn't mean that the elements are typeless
things; it means that their types aren't determined
simply by the fact that they're elements of a list.
In Lisp, every object carries its type around with it
(so to speak). In this respect, Lisp is different from
many other programming languages in which types are
attached to *variables* rather than to *objects*. The
type information is still there, it's just in a different
place.
Some functions that operate on lists may have
their own expectations of what sorts of things
will be in the lists. Those expectations should
be documented as part of the function's documentation.
When you do
(setq friends '(bush cheney))
the elements of the list are things called "symbols".
A symbol is in some ways a bit like a string, but
symbols and strings are not the same and are generally
not interchangeable. Symbols
- are written without quotation marks
- can't (without special measures) have spaces
and various other funny characters in their names
- can be compared against one another very
efficiently
- have various other bits of data associated with
them, besides their names
- don't (directly) support common string operations
like taking substrings, upcasing, searching and
so on
You can make a symbol whose name is "/dir", but it won't
be the same thing as the string "/dir". For a variety of
reasons, strings are better suited than symbols to
representing filenames and pathnames, so that's what
(X)Emacs uses.
--
Gareth McCaughan
.sig under construc
From: Randy Yates
Subject: Re: Very Basic LISP Question
Date:
Message-ID: <k6stf6ic.fsf@ieee.org>
Hi Gareth,
Thank you for your gentle and informative response!
Gareth McCaughan <················@pobox.com> writes:
> Randy Yates wrote:
>
>> My only use for lisp at the moment is for xemacs,
>
> There are some emacs-related Usenet groups where you
> might get a more focused answer. However ...
>
>> BUT..., it doesn't take just any ole' list - it MUST have a list of
>> STRINGS. For example, this doesn't work:
>>
>> (packages-find-package-data-path '(/dir))
>>
>> I get a "Wrong argument: sequencep, /dir" error.
>> However, if I use a string for the list elements
>> everything is fine:
>>
>> (packages-find-package-data-path '("/dir"))
>>
>> returns "nil".
>>
>> So my problem is this: After reading the Winston text,
>> it appeared that the members of a list are some sort
>> of typeless things. For example, the command
>>
>> (setq friends '(bush cheney))
>>
>> works just fine, but what are the data types of the
>> elements "bush" and "cheney"? Going back to the
>> xemacs command what type is the list (/dir) if it's
>> not a string? Can a list element have any type? If
>> not, what subset of types may they assume?
>
> The elements of a list can have any type(s).
>
> That doesn't mean that the elements are typeless
> things; it means that their types aren't determined
> simply by the fact that they're elements of a list.
>
> In Lisp, every object carries its type around with it
> (so to speak). In this respect, Lisp is different from
> many other programming languages in which types are
> attached to *variables* rather than to *objects*. The
> type information is still there, it's just in a different
> place.
>
> Some functions that operate on lists may have
> their own expectations of what sorts of things
> will be in the lists. Those expectations should
> be documented as part of the function's documentation.
>
> When you do
>
> (setq friends '(bush cheney))
>
> the elements of the list are things called "symbols".
So is ""/dir"" a symbol too? It is an element of a list.
> A symbol is in some ways a bit like a string, but
> symbols and strings are not the same and are generally
> not interchangeable. Symbols
> - are written without quotation marks
> - can't (without special measures) have spaces
> and various other funny characters in their names
> - can be compared against one another very
> efficiently
> - have various other bits of data associated with
> them, besides their names
> - don't (directly) support common string operations
> like taking substrings, upcasing, searching and
> so on
>
> You can make a symbol whose name is "/dir", but it won't
> be the same thing as the string "/dir". For a variety of
> reasons, strings are better suited than symbols to
> representing filenames and pathnames, so that's what
> (X)Emacs uses.
Thanks for that explanation, Gareth, but allow me to
ask a more direct question. When I execute the command
(setq friends '(bush cheney))
what "types" are the list elements "bush" and "cheney"? You
say they're symbols, but does that fact clarify their data
type?
Perhaps it would be useful to actually talk about how
symbols are actually organized in memory. For example, is
it a structure with a label (i.e., the name), a type (float,
char[], etc.), a function, etc.?
I don't mean to be long-winded, but I'm not going to pretend I
understand when I don't. Thanks for your help.
--
% Randy Yates % "Rollin' and riding and slippin' and
%% Fuquay-Varina, NC % sliding, it's magic."
%%% 919-577-9882 %
%%%% <·····@ieee.org> % 'Living' Thing', *A New World Record*, ELO
http://home.earthlink.net/~yatescr
Randy Yates wrote:
>> When you do
>>
>> (setq friends '(bush cheney))
>>
>> the elements of the list are things called "symbols".
>
> So is ""/dir"" a symbol too? It is an element of a list.
>
(Assuming you mean "/dir")
No, the reader will read that in as a string.
Generally the syntax for a symbol is 'symbol-name, but you can use special
characters such as whitespace etc. by quoting it like this: '|weird sYmBol|
Don't, though. It's hard to type.
A symbol can have a variable-value and a function-value; the ' character
expands to (quote ...), which makes it use the actual symbol instead of one
of those values. If you don't quote it, it will use the function-value in
the leftmost position of a form and variable-value elsewhere.
(Bindings, actually, not values; don't take it too literally.)
>> A symbol is in some ways a bit like a string, but
>> symbols and strings are not the same and are generally
>> not interchangeable. Symbols
>> - are written without quotation marks
>> - can't (without special measures) have spaces
>> and various other funny characters in their names
>> - can be compared against one another very
>> efficiently
>> - have various other bits of data associated with
>> them, besides their names
>> - don't (directly) support common string operations
>> like taking substrings, upcasing, searching and
>> so on
>>
>> You can make a symbol whose name is "/dir", but it won't
>> be the same thing as the string "/dir". For a variety of
>> reasons, strings are better suited than symbols to
>> representing filenames and pathnames, so that's what
>> (X)Emacs uses.
>
> Thanks for that explanation, Gareth, but allow me to
> ask a more direct question. When I execute the command
>
> (setq friends '(bush cheney))
>
> what "types" are the list elements "bush" and "cheney"? You
> say they're symbols, but does that fact clarify their data
> type?
>
> Perhaps it would be useful to actually talk about how
> symbols are actually organized in memory. For example, is
> it a structure with a label (i.e., the name), a type (float,
> char[], etc.), a function, etc.?
>
Essentially yes. The same structure exists in every other programming
language, but in Lisp you get to keep it at runtime.
> I don't mean to be long-winded, but I'm not going to pretend I
> understand when I don't. Thanks for your help.
This'll be for Common Lisp, not ELisp, but anyhow.
A symbol is essentially a structure with the following fields:
0: Name - a string that tells things how to print it.
1: Package - a reference to the package it's a part of.
2: Value - the symbol-value field, used when you dereference the symbol in
non-first parts of a form.
3: Function - the symbol-function field, used when you dereference it in the
first of a form, or if it's part of a FUNCTION special form. (function
symbol), or #'symbol.
4: Property list. This is a holdover from when AI seemed like a good idea,
and isn't generally a very good idea. Ignore it until you understand the
rest.
Randy Yates wrote:
> > When you do
> >
> > (setq friends '(bush cheney))
> >
> > the elements of the list are things called "symbols".
>
> So is ""/dir"" a symbol too? It is an element of a list.
No, it's a string. *Any* type of object can be put into
a list. Symbols, strings, numbers, other lists, whatever.
The thing that makes the elements of the list '(bush cheney)
symbols rather than strings is not the fact that they're
elements of a list. It's the fact that they *are* symbols,
and that's determined by the syntax of the language.
Similarly, if you write '(1 2 3 4), the fact that those
elements are numbers is a result of the fact that you
wrote numbers. And if you write '(1 "two" three) then
you get a list containing a number, a string and a symbol.
> Thanks for that explanation, Gareth, but allow me to
> ask a more direct question. When I execute the command
>
> (setq friends '(bush cheney))
>
> what "types" are the list elements "bush" and "cheney"? You
> say they're symbols, but does that fact clarify their data
> type?
Yes; "symbol" is the name of a data type.
> Perhaps it would be useful to actually talk about how
> symbols are actually organized in memory. For example, is
> it a structure with a label (i.e., the name), a type (float,
> char[], etc.), a function, etc.?
OK. A symbol is a thing with the following attributes. I'll
explain what they mean after I give the list. The list may
not be complete.
- A name.
- A value-as-a-variable.
- A value-as-a-function.
- A property list.
The external representation of a symbol is simply its name,
without any need for quotation marks or anything like that.
That's the reason why symbol names can't contain arbitrary
characters, as I mentioned before.
(Note: Actually, in at least some versions of Lisp
they can, but you need to jump through some (not very
onerous) hoops to make that happen. Most symbols'
names use a limited repertoire of characters.
There is at most one symbol with any given name, and
the system maintains a mapping from names to symbols.
This mapping happens "at read time", which is to say
before the compiler or interpreter actually has to do
any work.
(Note: Actually, in at least some versions of Lisp
it *is* possible to have multiple symbols with the
same name; the details aren't important, and the
lie I told above is probably less misleading than
the truth.)
Symbols are used as the names of variables and functions.
This isn't so very different from other languages, but
in Lisp the symbol itself is available at runtime. If you
don't see why this might be useful, don't worry about it.
(Note: Actually, what I've said about symbols naming
variables may mislead, because it rather implies that
every variable access goes via a symbol. I think that's
actually true in Emacs Lisp, but it isn't true in most
other Lisp implementations for efficiency reasons.)
Symbols are used as the names of all kinds of other
things: types, classes (in versions of Lisp that have
classes), labels (in versions of Lisp that have an
equivalent of "goto"), and so on. Those other things,
however, are generally not stored *in* the symbol
data structure, whereas the variable and function
values generally are.
And every symbol has a funny thing called a "property
list" which is simply, well, a list. There are mechanisms
for adding things to, and removing things from, the
property list of a symbol. In ancient prehistoric
versions of Lisp, the (function and variable) values
of a symbol were stored in the property list. They aren't
any more, and property lists aren't used much now.
--
Gareth McCaughan
.sig under construc
Randy Yates <·····@ieee.org> writes:
> Perhaps it would be useful to actually talk about how
> symbols are actually organized in memory. For example, is
> it a structure with a label (i.e., the name), a type (float,
> char[], etc.), a function, etc.?
In GNU Emacs 21, that is a struct Lisp_Symbol, defined in emacs/src/lisp.h.
The structure is commented better in current CVS versions than in 21.3.