Re: Mis-features of let

[rgb]

> > 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.