From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: Mis-features of let Date: Tue, 19 Apr 2005 00:31:40 -0400 Organization: Bell Sympatico Message-ID: <87y8bfwgrv.fsf-monnier+gnu.emacs.help@gnu.org> 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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1113885979 6516 80.91.229.2 (19 Apr 2005 04:46:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 19 Apr 2005 04:46:19 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Apr 19 06:46:18 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DNkcl-0001yI-Gn for geh-help-gnu-emacs@m.gmane.org; Tue, 19 Apr 2005 06:46:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DNkgy-0003Kl-Td for geh-help-gnu-emacs@m.gmane.org; Tue, 19 Apr 2005 00:50:32 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews.google.com!news3.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:pfDd0oPwoExJSxBB/HxoNrw81KY= Original-Lines: 64 Original-NNTP-Posting-Host: 67.68.216.125 Original-X-Complaints-To: abuse@sympatico.ca Original-X-Trace: news20.bellglobal.com 1113885101 67.68.216.125 (Tue, 19 Apr 2005 00:31:41 EDT) Original-NNTP-Posting-Date: Tue, 19 Apr 2005 00:31:41 EDT Original-Xref: shelby.stanford.edu gnu.emacs.help:130241 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:25809 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:25809 >> Another way is to post here an example of a specific behavior which >> you find counter intuitive (basically write a bug report, but asking >> why it works that way, rather than claiming it's a bug ;-). > I didn't say it *was* a bug, but "a bug waiting to happen". Perhaps I didn't mean to imply that you claimed it was a bug. > thats an idiom you're not familiar with. Sorry. But my other > statement should have made it clear I wasn't claiming it was a bug: It was indeed quite clear and I understood it just fine, thank you. > So your saying "no mention in any Elisp manual section that covers > plists or symbol function cells about this behavior" isn't specific > enough? Indeed, because I have no clue what "this behavior" is. > I'm sure your not implying I should have actually listed every section > that refers to either of these subjects so I can't tell what more you > expected me to cite. No, it wouldn't have helped. > 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. > 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. > since the resulting behavior would apparently be > undefined (as evidenced by the example in my previous post). I see no such evidence. Can you explain what other behavior you expected? > Hence, a bug waiting to happen. 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". Stefan