From: "rgb" <rbielaws@i1.net>
Subject: Re: Mis-features of let
Date: 19 Apr 2005 18:04:40 -0700 [thread overview]
Message-ID: <1113959080.090388.307740@f14g2000cwb.googlegroups.com> (raw)
In-Reply-To: 85sm1mh1f6.fsf@lola.goethe.zz
> > 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.
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. 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.
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.
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.
I appreciate all the patience, and more importantly, persistance
in getting me straightened out.
Thanks
next prev parent reply other threads:[~2005-04-20 1: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 [this message]
2005-04-20 10:04 ` David Kastrup
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=1113959080.090388.307740@f14g2000cwb.googlegroups.com \
--to=rbielaws@i1.net \
/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).