From: David Kastrup <dak@gnu.org>
Subject: Re: Mis-features of let
Date: Wed, 20 Apr 2005 12:04:17 +0200 [thread overview]
Message-ID: <854qe1hihq.fsf@lola.goethe.zz> (raw)
In-Reply-To: 1113959080.090388.307740@f14g2000cwb.googlegroups.com
"rgb" <rbielaws@i1.net> writes:
>> > and use of functions such as fset and put have undefined results
>> > (which I showed in my examples).
>>
>> No, you didn't. You uninterned the symbol, after which it was no
>> longer available under the name 'foo.
>>
>> But if you had done (setq woozle 'foo) before uninterning it,
>> woozle would have continued to be a perfectly valid handle to the
>> symbol, even though 'foo no longer was able to access it.
>
> After all the coding I've done I had no idea my understanding of
> what was going on was so fundamentally flawed. It's easy to
> pinpoint just where this missunderstanding stems from though.
>
> Elisp reference:
>
> 8. Symbols
>
> A symbol is an object with a unique name.
Well, that's stressing it. Obviously there can be multiple symbols
with the same print name, and symbols are not required to actually
have an obarray name, whether in the default obarray or elsewhere.
You can't change the various names of a symbol once it has been
created (in particular not the print name), but you can detach the
symbol from its associated obarray, if any.
> 8.3 Creating and Interning Symbols
>
> To understand how symbols are created in GNU Emacs Lisp, you must
> know how Lisp reads them. Lisp must ensure that it finds the same
> symbol every time it reads the same set of characters. Failure to
> do so would cause complete confusion.
>
> I was under the impression that let must be creating a symbol with
> the name I specified if one didn't already exist.
Oh, but it does. It is creating a symbol with the unique name IN
OBARRAY if it did not already exist. After uninterning it, none with
that name exists IN OBARRAY.
> Many tests seemed to confirm this view but some did not, triggering
> this dialog.
>
> What you appear to be saying is that
>
> 1. symbols do not have unique names they have unique handles.
You can't change the name of a symbol, and a symbol is interned at
most in one obarray, but it can be uninterned. It will still print
the same, though, but it will no longer be accessible by that name.
> 2. the lisp reader won't necessarily find the same symbol every
> time. It will find whatever symbol is interned in the global
> obarray with a name equal to the name being read at the time.
Yes.
> So, although it almost always is the same, nothing actually ensures
> it is the same.
>
> Hopefully there are no more such flaws in my understanding.
Looks more or less straight. Note that there is not much freedom with
symbol names. The name you choose stays with it from the start, but
you can pick an initial obarray (if you use "intern") or not (if you
create the symbol using "make-symbol"). In either case, names can't
be changed, and the only remaining operation is uninterning it. This
does not destroy the symbol: it still prints the same, and as long as
references to it exist, it won't get garbage-collected.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
next prev parent reply other threads:[~2005-04-20 10:04 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-18 12:56 Defadvice use Matthias
2005-04-18 17:11 ` rgb
2005-04-18 17:25 ` Johan Bockgård
2005-04-18 19:05 ` rgb
2005-04-18 19:43 ` Stefan Monnier
2005-04-19 0:15 ` rgb
2005-04-19 0:28 ` Stefan Monnier
2005-04-19 3:48 ` Mis-features of let (was Defadvice use) rgb
2005-04-19 4:31 ` Mis-features of let Stefan Monnier
2005-04-19 6:38 ` rgb
2005-04-19 12:21 ` Stefan Monnier
2005-04-19 20:31 ` rgb
2005-04-19 21:45 ` David Kastrup
2005-04-19 12:55 ` Barry Margolin
2005-04-19 20:31 ` rgb
2005-04-20 4:12 ` Barry Margolin
2005-04-19 21:10 ` rgb
2005-04-19 21:57 ` Kevin Rodgers
2005-04-19 22:00 ` David Kastrup
2005-04-20 1:04 ` rgb
2005-04-20 10:04 ` David Kastrup [this message]
2005-04-20 11:57 ` Stefan Monnier
2005-04-20 14:41 ` Thien-Thi Nguyen
2005-04-19 9:41 ` Thien-Thi Nguyen
2005-04-19 5:07 ` Defadvice use Barry Margolin
2005-04-18 17:52 ` Stefan Monnier
2005-04-18 21:07 ` Matthias
2005-04-18 23:20 ` Stefan Monnier
2005-04-18 20:28 ` Kevin Rodgers
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=854qe1hihq.fsf@lola.goethe.zz \
--to=dak@gnu.org \
/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).