From: Drew Adams <drew.adams@oracle.com>
To: Jean Abou Samra <jean@abou-samra.fr>, Heime <heimeborgia@protonmail.com>
Cc: "tomas@tuxteam.de" <tomas@tuxteam.de>,
"help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: RE: [External] : Re: Calling a function with undefined symbol
Date: Mon, 31 Oct 2022 17:00:32 +0000 [thread overview]
Message-ID: <SJ0PR10MB54882A658A874EFDF437F6E3F3379@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <BB76B557-397A-4BEF-A0C8-28946C9299A1@abou-samra.fr>
> > The Lisp manual says that a symbol is an object with a name.
>
> This can be interpreted as the correct definition, but also as a wrong
> definition where a symbol is necessarily associated with a defined
> variable. Better said: a symbol is an object that represents a name.
Not really. A symbol can "represent" any number of
things, (including a name, or multiple names - of
anything) - whatever you like. But a symbol normally
_has_ a name, as one of its properties.
OP:
Function `make-symbol' requires a name, to create a
symbol. Function `symbol-name' returns the name of
a symbol.
A symbol is indeed a Lisp object - an atom that has
a name and possibly other properties (value as a
variable, function definition,...).
The very first sentence of the Elisp chapter about
Symbols says this:
A “symbol” is an object with a unique name.
And node Symbol Components tells you this:
The print name cell _always_ holds a string, and
cannot be changed.
The print name cell holds the string that is the
name of a symbol. Since symbols are represented
textually by their names, it is important not to
have two symbols with the same name.[*]
Node Creating and Interning Symbols tells you:
When the Lisp reader encounters a symbol, it reads
all the characters of the name.... If a symbol
with the desired name is found, the reader uses
that symbol. If the obarray does not contain a
symbol with that name, the reader makes a new
symbol and adds it to the obarray.
On the other hand, it is possible, but unusual, for
a symbol to be unnamed, aka "uninterned". But you
need not worry about this unusual situation when
starting to learn about Lisp. You should instead
think of a symbol as a Lisp object that _has a name_
(and possibly other properties). (Node Creating
and Interning Symbols also tells you about
uninterned symbols.)
___
Yes, _read the manual_. You read a bit about symbols
-- good. Read that bit again. And again. It isn't
rocket science, and lots of effort has gone into
trying to explain things. Read an introduction to
any Lisp - all Lisps have symbols. And try the
functions involving symbols.
Read the Intro to Elisp manual that comes with Emacs.
___
[*] More precisely, there cannot be two symbols with
the same name _in the same obarray_. An obarray is
essentially a symbol namespace. Each obarray can
have a symbol with any name (that's unique in that
obarray). Multiple obarrays can each have a symbol
`foo', that is, a symbol named "foo". But those are
separate, independent symbols, not the same Lisp
object.
next prev parent reply other threads:[~2022-10-31 17:00 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 8:15 Calling a function with undefined symbol Heime
2022-10-31 8:32 ` Jean Abou Samra
2022-10-31 8:42 ` tomas
2022-10-31 8:57 ` Heime
2022-10-31 9:07 ` tomas
2022-10-31 9:24 ` Jean Abou Samra
2022-10-31 9:43 ` Heime
2022-10-31 9:58 ` Jean Abou Samra
2022-10-31 10:57 ` Heime
2022-10-31 17:00 ` Drew Adams [this message]
2022-10-31 17:10 ` [External] : " Emanuel Berg
2022-11-01 4:11 ` Drew Adams
2022-11-01 5:24 ` tomas
2022-11-01 15:58 ` Drew Adams
2022-11-01 16:13 ` tomas
2022-11-01 19:22 ` Drew Adams
2022-10-31 12:29 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-10-31 15:37 ` Emanuel Berg
2022-11-02 12:14 ` Michael Heerdegen
2022-11-02 14:25 ` Sam Steingold
2022-11-02 16:40 ` Michael Heerdegen
2022-11-02 17:28 ` Emanuel Berg
2022-11-02 23:04 ` Emanuel Berg
2022-11-03 11:09 ` Michael Heerdegen
2022-11-03 12:15 ` Emanuel Berg
2022-11-04 12:16 ` Michael Heerdegen
2022-11-05 14:32 ` Emanuel Berg
2022-11-05 23:22 ` Michael Heerdegen
2022-11-06 20:17 ` Emanuel Berg
2022-11-07 16:03 ` Michael Heerdegen
2022-11-07 16:50 ` [External] : " Drew Adams
2022-11-07 16:52 ` Emanuel Berg
2022-11-08 15:52 ` Michael Heerdegen
2022-11-08 19:15 ` tomas
2022-11-08 19:57 ` Michael Heerdegen
2022-11-08 20:47 ` tomas
2022-11-08 21:35 ` Sam Steingold
2022-11-08 23:53 ` Michael Heerdegen
2022-11-09 15:32 ` Sam Steingold
2022-11-09 15:59 ` Michael Heerdegen
2022-11-16 19:07 ` Emanuel Berg
2022-11-16 21:40 ` [External] : " Drew Adams
2022-11-16 21:55 ` Emanuel Berg
2022-11-04 14:33 ` Michael Heerdegen
2022-11-05 12:57 ` Emanuel Berg
2022-10-31 11:34 ` Emanuel Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR10MB54882A658A874EFDF437F6E3F3379@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=heimeborgia@protonmail.com \
--cc=help-gnu-emacs@gnu.org \
--cc=jean@abou-samra.fr \
--cc=tomas@tuxteam.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).