> > 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 <sym> <val>) has no interaction > with things like (set <sym> <val>) or (let ((<sym> <val>)) ...) 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. _______________________________________________ Help-gnu-emacs mailing list Help-gnu-emacs@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnu-emacs