From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "rgb" Newsgroups: gmane.emacs.help Subject: Re: Mis-features of let Date: 18 Apr 2005 23:38:20 -0700 Organization: http://groups.google.com Message-ID: <1113892700.139927.168000@g14g2000cwa.googlegroups.com> References: <1113844268.703229.310830@g14g2000cwa.googlegroups.com> <1113851147.155814.314630@g14g2000cwa.googlegroups.com> <87y8bfzx9z.fsf-monnier+gnu.emacs.help@gnu.org> <1113869741.838603.250620@o13g2000cwo.googlegroups.com> <87pswry5py.fsf-monnier+gnu.emacs.help@gnu.org> <1113882527.264397.292310@o13g2000cwo.googlegroups.com> <87y8bfwgrv.fsf-monnier+gnu.emacs.help@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: sea.gmane.org 1113892629 20909 80.91.229.2 (19 Apr 2005 06:37:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 19 Apr 2005 06:37:09 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Apr 19 08:37:07 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DNmLv-0003TZ-5T for geh-help-gnu-emacs@m.gmane.org; Tue, 19 Apr 2005 08:36:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DNmQ9-0002Xe-55 for geh-help-gnu-emacs@m.gmane.org; Tue, 19 Apr 2005 02:41:17 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews.google.com!g14g2000cwa.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 74 Original-NNTP-Posting-Host: 63.229.223.29 Original-X-Trace: posting.google.com 1113892704 19288 127.0.0.1 (19 Apr 2005 06:38:24 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Tue, 19 Apr 2005 06:38:24 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: g14g2000cwa.googlegroups.com; posting-host=63.229.223.29; posting-account=C7LM4w0AAAD23IRuMuUUJVCLQTuHhTK8 Original-Xref: shelby.stanford.edu gnu.emacs.help:130245 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:25813 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:25813 > > I also expressed "The `feature' is only _implied_, not documented." > > IOW, no place (as in anywhere in the user or reference manual) do I > > find a warning or even a passing mention that a symbol, created by let > > or let* is handled differently from a symbol created through set, > > fset, any of the def... forms, intern, etc. > > Show us in what way they are treated differently. I.e. show us some elisp > code and the result(s) returned and then tell us what result you expected > instead and why. Well, I thought I did. I mean I even put comments next to results that said "external value unexpectedly changed" and "now unexpectedly doesn't" > > From what you've said (and experiments point to you being correct), no > > one should ever use put, fset, setplist etc on any symbol whose origin > > might be let or let* > > No, that's not what I said. Simply (fset ) has no interaction > with things like (set ) or (let (( )) ...) and > vice versa. Aaah. So thats why you don't understand. You just don't realize the implications of what you're saying. Look at the example again keeping in mind the comments state why the behavior of put, fset etc must be considered undefined when the symbol is part of a let. The lifetime of those cells of the symbol is almost completely unpredictable. Do you now see what I'm getting at? Only the lifetime of the value cell is predictable on a symbol within a let. That makes the other cells unsafe to touch because their lifetime is unpredictable. > Think of it this way: in elisp a symbol is an object in memory with the > following 4 fields: > > name, function, value, plist > > `fset' affects the `function' field, while `set' and `let' affect the > `value' field of a symbol. > > A "variable" is a more abstract concept, corresponding more or less to > a location in memory holding a value. E.g. in elisp the `value' field of > a symbol is used as a "variable". > If symbols created by let refer to an abstract concept then you're reinforcing my notion that they have a different definition from the symbols described in Elisp:Symbols which are all quite concrete. In my example you will see that in one case the property stored by test1 in the property cell of symbol a01 has a limited life and in the other case it has indefinite life. How can test1 know if the property will have limited or indefinite life? If it expects limited then indefinite could cause bugs, if it expects indefinite then limited will very likely cause bugs. If it can't tell then it's an unsafe operation and users should be warned that such operations are not predictable (undefined). There are instances where I can tell the life *will be* limited but I don't belive it's possible to tell that it's *not* limited. This is where the danger lies. If you ever use fset, put etc on a symbol whose plist or function cell lifetime is unknown, bugs are likely.