Defadvice use

Defadvice use

[Matthias]

Hi,

I have the following problem: How do I advice a function so that
within that function, the function `read-minibuffer' (for example)
calls the definition of another function, say `my-read-minibuffer'?

I'm trying to use an advice around the function; the advice providing
a binding of the symbol `read-minibuffer' to the definition of
`my-read-minibuffer'. Like the following:

(defadvice la-fonction
  (around la-fonction-extended enable compile)
  "Documentation"
   (let (f1)
     (fset 'f1 read-minibuffer)
     (fset 'read-minibuffer my-read-minibuffer)
     ad-do-it
     (fset 'read-minibuffer f1)))

Any comment? Is it silly? Is there a better way? Any idea?

Thanks for your help,
-- 
Matthias

Re: Defadvice use

[rgb]

Matthias wrote:
> Hi,
>
> I have the following problem: How do I advice a function so that
> within that function, the function `read-minibuffer' (for example)
> calls the definition of another function, say `my-read-minibuffer'?
>
> I'm trying to use an advice around the function; the advice providing
> a binding of the symbol `read-minibuffer' to the definition of
> `my-read-minibuffer'. Like the following:
>
> (defadvice la-fonction
>   (around la-fonction-extended enable compile)
>   "Documentation"
>    (let (f1)
>      (fset 'f1 read-minibuffer)
>      (fset 'read-minibuffer my-read-minibuffer)
>      ad-do-it
>      (fset 'read-minibuffer f1)))
>
> Any comment? Is it silly? Is there a better way? Any idea?
>

I asked the 'is there a better way' question not too long ago
concerning the problem below and got no response so this might
be as good as it gets.  I do it slightly different from your
example.  I think you really don't need f1 in your advice code.

; I don't like bookmark mouse-2 opening the file in another window.
; There doesn't seem to be any other way to fix the problem.  The
; theory here is to temporarily re-define the function that the mouse
; handler does call giving it the definition of the function I wish it
; would call.
(defadvice bookmark-bmenu-other-window-with-mouse
  (around my-fix first () activate) ;rgb 2004
  "Changes behavior to open file in same window, not other-window."
  (let (bookmark-bmenu-other-window)
    (fset 'bookmark-bmenu-other-window
          (symbol-function 'bookmark-bmenu-this-window))
    ad-do-it))

Re: Defadvice use

[Johan Bockgård]

"rgb" <rbielaws@i1.net> writes:

> ; I don't like bookmark mouse-2 opening the file in another window.
> ; There doesn't seem to be any other way to fix the problem.  The
> ; theory here is to temporarily re-define the function that the mouse
> ; handler does call giving it the definition of the function I wish it
> ; would call.
> (defadvice bookmark-bmenu-other-window-with-mouse
>   (around my-fix first () activate) ;rgb 2004
>   "Changes behavior to open file in same window, not other-window."
>   (let (bookmark-bmenu-other-window)
>     (fset 'bookmark-bmenu-other-window
>           (symbol-function 'bookmark-bmenu-this-window))
>     ad-do-it))

This permanently redefines `bookmark-bmenu-other-window'.

-- 
Johan Bockgård

Re: Defadvice use

[rgb]

Johan Bockgård wrote:
> "rgb" <rbielaws@i1.net> writes:
>
> > ; I don't like bookmark mouse-2 opening the file in another window.
> > ; There doesn't seem to be any other way to fix the problem.  The
> > ; theory here is to temporarily re-define the function that the
mouse
> > ; handler does call giving it the definition of the function I wish
it
> > ; would call.
> > (defadvice bookmark-bmenu-other-window-with-mouse
> >   (around my-fix first () activate) ;rgb 2004
> >   "Changes behavior to open file in same window, not other-window."
> >   (let (bookmark-bmenu-other-window)
> >     (fset 'bookmark-bmenu-other-window
> >           (symbol-function 'bookmark-bmenu-this-window))
> >     ad-do-it))
>
> This permanently redefines `bookmark-bmenu-other-window'.
>

I don't understand why.
Doesn't (let (bookmark-bmenu-other-window) ...) have limited life.
Perhaps my experiments were flawed but they made me think this worked.
Could you explain?

Re: Defadvice use

[Stefan Monnier]

> Doesn't (let (bookmark-bmenu-other-window) ...) have limited life.

  (let (bookmark-bmenu-other-window) ...)

only affects the bookmark-bmenu-other-window *variable*, not the
bookmark-bmenu-other-window function.


        Stefan

Re: Defadvice use

[rgb]

Stefan Monnier wrote:
> > Doesn't (let (bookmark-bmenu-other-window) ...) have limited life.
>
>   (let (bookmark-bmenu-other-window) ...)
>
> only affects the bookmark-bmenu-other-window *variable*, not the
> bookmark-bmenu-other-window function.
>

If that isn't a bug waiting to happen I don't know what is.
You appear to be asserting that it's documented to work that
way but I'd counter with 2 arguments.

1.  The `feature' is only _implied_, not documented.  There is
    no mention in any Elisp manual section that covers plists
    or symbol function cells about this behavior.

2.  The `feature' invalidates much of the documented behavior of
    symbols unless you know how the symbol was created.

Look at this:

(defun test1 ()
  (let (a01)
    (put 'a01 'hold "this")
    (symbol-plist 'a01)))

(put 'a01 'hold "that") ; insure symbol already exists
(symbol-plist 'a01)
 => (hold "that")       ; value is there as expected

(test1)
 => (hold "this")

(symbol-plist 'a01)
 => (hold "this")       ; external value unexpectedly changed

(unintern "a01")        ; insure it doesn't exist
(symbol-plist 'a01)
 => nil                 ; no error.

(test1)
 => (hold "this")

(symbol-plist 'a01)    ; Given the external value should change
 => nil                ; it now unexpectedly doesn't

It's obviously impossible to easily create any function or
macro that manipulates function or property cells unless you
can guarantee none of the symbols are ever created by let.

Since it appears to be by design, I'd be terribly curious to
see any archive of discussions concerning why this is
appropriate behavior.

Re: Defadvice use

[Stefan Monnier]

>> > Doesn't (let (bookmark-bmenu-other-window) ...) have limited life.
>> (let (bookmark-bmenu-other-window) ...)
>> only affects the bookmark-bmenu-other-window *variable*, not the
>> bookmark-bmenu-other-window function.
> If that isn't a bug waiting to happen I don't know what is.
> You appear to be asserting that it's documented to work that
> way but I'd counter with 2 arguments.
[...]

I must say I have no idea what you're talking about.
Maybe it's me, but since I believe I'm pretty familiar with those concepts,
I'll assume you either expressed yourself poorly, or you don't really
understand the notions of symbols and variables.  Try to reread the elisp
manual, especially the part describing variables, symbols, and things like
symbol-function, symbol-value, symbol-plist, ...

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

It'd also be helpful to cite relevant parts of the elisp manual which lead
you to your mis-understanding, so we can try and improve it.


        Stefan

Re: Mis-features of let (was Defadvice use)

[rgb]

> bla bla

Yes.  Communication with 'inteligent beings' is, for me, quite often
an extreemly difficult and error prone task.  Believe it or not I
spent over 2 hrs on that post trying to be clear. 3 on this.

> 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
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:
"Since it appears to be by design, I'd be terribly curious to see any
archive of discussions concerning why this is appropriate behavior."

> It'd also be helpful to cite relevant parts of the elisp manual
> which lead you to your mis-understanding, so we can try and improve
> it.

So your saying "no mention in any Elisp manual section that covers
plists or symbol function cells about this behavior" isn't specific
enough?  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.

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.

>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* since the resulting behavior would apparently be
undefined (as evidenced by the example in my previous post).

Hence, a bug waiting to happen.

Re: Mis-features of let

[Stefan Monnier]

>> 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 <sym> <val>) has no interaction
with things like (set <sym> <val>) or (let ((<sym> <val>)) ...) 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

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.

Re: Mis-features of let

[Stefan Monnier]

> If symbols created by let refer to an abstract concept then you're

`let' does not create symbols.


        Stefan

Re: Mis-features of let

[rgb]

Now that I've slept, maybe I'll understand.  Can we try again

Stefan Monnier wrote:
> > If symbols created by let refer to an abstract concept then you're
>
> `let' does not create symbols.
>

Ok, semantic error.  From the point of view of a program the
symbol is being created and destroyed but actually it must
just be getting interned and uninterned.  I don't know of a
way to tell the difference but I can't think of a reason I'd
need to know other than to use the correct term here.

So if I conceed it isn't being `created' and you replace my
erroneous use of create with intern does it make any difference?
If not, what explains this?

(defun test ()
  (let (foo)
    (put 'foo 'hold "this ")
    (symbol-plist 'foo)))
=> test

(unintern "foo")
=> t

(symbol-plist 'foo)
=> nil

(test)
=> (hold "this ")

(symbol-plist 'foo)
=> nil

The lifetime of the plist is obviously limited.

Re: Mis-features of let

[David Kastrup]

"rgb" <rbielaws@i1.net> writes:

> Now that I've slept, maybe I'll understand.  Can we try again
>
> Stefan Monnier wrote:
>> > If symbols created by let refer to an abstract concept then you're
>>
>> `let' does not create symbols.
>
> Ok, semantic error.  From the point of view of a program the
> symbol is being created and destroyed but actually it must
> just be getting interned and uninterned.

Uh, no.

> I don't know of a way to tell the difference but I can't think of a
> reason I'd need to know other than to use the correct term here.
>
> So if I conceed it isn't being `created' and you replace my
> erroneous use of create with intern does it make any difference?
> If not, what explains this?
>
> (defun test ()
>   (let (foo)
>     (put 'foo 'hold "this ")
>     (symbol-plist 'foo)))
> => test
>
> (unintern "foo")
> => t
>
> (symbol-plist 'foo)
> => nil
>
> (test)
> => (hold "this ")
>
> (symbol-plist 'foo)
> => nil
>
> The lifetime of the plist is obviously limited.

Nonsense.  How would you explain this then:

(defun test ()
  (let (foo)
     (put 'foo 'hold "this ")
     (setq woozle 'foo)
     (symbol-plist 'foo)))
=> test

(unintern "foo")
=> t

(symbol-plist 'foo)
=> nil
(test)
=> (hold "this ")
(symbol-plist 'foo)
=> nil
(symbol-plist woozle)
=> (hold "this ")

The symbol is obviously still there.  It only is no longer associated
with the same name.  But as long as you took a snapshot of the symbol
before it became anonymous (that's what woozle does), you can still
refer to that snapshot, even though the symbol itself has no longer an
accessible name.  It does have a print name, though:

woozle
=> foo

Note that woozle is no longer the same as 'foo, since the association
of the symbol stored in woozle with the default obarray does no longer
exist.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Mis-features of let

[Barry Margolin]

In article <1113892700.139927.168000@g14g2000cwa.googlegroups.com>,
 "rgb" <rbielaws@i1.net> wrote:

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

The lifetimes of the other cells are totally unaffected by the the let, 
and nothing in the manual ever suggests that they would be.  It doesn't 
say they aren't, but it also doesn't say that let doesn't print 
anything.  Like I said in an earlier post, it's not necessary to list 
all the things that an operator doesn't do, since there are an infinite 
number of things it doesn't do.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Mis-features of let

[rgb]

> The lifetimes of the other cells are totally unaffected by the the
let,

This is where you are obviously wrong as I proved in my example.

> and nothing in the manual ever suggests that they would be.

This is the root of my argument, it does happen and nothing warns you.

Re: Mis-features of let

[Barry Margolin]

In article <1113942671.973916.309740@l41g2000cwc.googlegroups.com>,
 "rgb" <rbielaws@i1.net> wrote:

> > The lifetimes of the other cells are totally unaffected by the the
> let,
> 
> This is where you are obviously wrong as I proved in my example.

Are you talking about the example where you bound a symbol with let and 
then used put to add a property, and then you uninterned the symbol?  I 
already explained why that had the behavior you saw, and it has nothing 
to do with let affecting the property list.  It's because when you 
uninterned the symbol and then typed the symbol again, you got a 
different symbol than the one that was in the function.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Mis-features of let

[rgb]

> anything.  Like I said in an earlier post, it's not necessary to
> list all the things that an operator doesn't do, since there are an
> infinite number of things it doesn't do.

8.1 Symbol Components of the Elisp reference says:

The "value cell" holds the current value of the symbol as a
     variable.  When a symbol is used as a form, the value of the
     form is the contents of the symbol's value cell.  See
     `symbol-value' in *Note Accessing Variables::.

It also says:

  The value cell holds the symbol's value as a variable (*note
  Variables::).  That is what you get if you evaluate the symbol as
  a Lisp expression (*note Evaluation::).

With no statements anywhere to the contrary, these statements imply
that any use of the term *variable* is a reference to a symbol's
value cell.

By implying or outright claiming that let has no effect on the
print-name, function, or plist cells of the symbol passed to let the
manual creates a hazard that someone like me is almost certain to
fall into. (As I did.)  Nothing warned me of the danger that the
symbol made available under let is not a normal symbol and use
of functions such as fset and put have undefined results (which
I showed in my examples).

Re: Mis-features of let

[Kevin Rodgers]

rgb wrote:
>>anything.  Like I said in an earlier post, it's not necessary to
>>list all the things that an operator doesn't do, since there are an
>>infinite number of things it doesn't do.
> 
> 
> 8.1 Symbol Components of the Elisp reference says:
> 
> The "value cell" holds the current value of the symbol as a
>      variable.  When a symbol is used as a form, the value of the
>      form is the contents of the symbol's value cell.  See
>      `symbol-value' in *Note Accessing Variables::.
> 
> It also says:
> 
>   The value cell holds the symbol's value as a variable (*note
>   Variables::).  That is what you get if you evaluate the symbol as
>   a Lisp expression (*note Evaluation::).
> 
> With no statements anywhere to the contrary, these statements imply
> that any use of the term *variable* is a reference to a symbol's
> value cell.
> 
> By implying or outright claiming that let has no effect on the
> print-name, function, or plist cells of the symbol passed to let the
> manual creates a hazard that someone like me is almost certain to
> fall into. (As I did.)  Nothing warned me of the danger that the
> symbol made available under let is not a normal symbol and use
> of functions such as fset and put have undefined results (which
> I showed in my examples).

set : fset :: let : flet

-- 
Kevin Rodgers

Re: Mis-features of let

[David Kastrup]

"rgb" <rbielaws@i1.net> writes:

> By implying or outright claiming that let has no effect on the
> print-name, function, or plist cells of the symbol passed to let

let _has_ no effect on the print-name, function of plist cells of the
symbol.

> the manual creates a hazard that someone like me is almost certain
> to fall into. (As I did.)  Nothing warned me of the danger that the
> symbol made available under let is not a normal symbol

It is a normal symbol.

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Mis-features of let

[rgb]

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

Re: Mis-features of let

[David Kastrup]

"rgb" <rbielaws@i1.net> writes:

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

Well, that's stressing it.  Obviously there can be multiple symbols
with the same print name, and symbols are not required to actually
have an obarray name, whether in the default obarray or elsewhere.

You can't change the various names of a symbol once it has been
created (in particular not the print name), but you can detach the
symbol from its associated obarray, if any.

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

Oh, but it does.  It is creating a symbol with the unique name IN
OBARRAY if it did not already exist.  After uninterning it, none with
that name exists IN OBARRAY.

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

You can't change the name of a symbol, and a symbol is interned at
most in one obarray, but it can be uninterned.  It will still print
the same, though, but it will no longer be accessible by that name.

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

Yes.

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

Looks more or less straight.  Note that there is not much freedom with
symbol names.  The name you choose stays with it from the start, but
you can pick an initial obarray (if you use "intern") or not (if you
create the symbol using "make-symbol").  In either case, names can't
be changed, and the only remaining operation is uninterning it.  This
does not destroy the symbol: it still prints the same, and as long as
references to it exist, it won't get garbage-collected.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Mis-features of let

[Stefan Monnier]

> You can't change the various names of a symbol once it has been
> created (in particular not the print name), but you can detach the

Try (subst-char-in-string ?a ?d (symbol-name 'car) t)


        Stefan

Re: Mis-features of let

[Thien-Thi Nguyen]

"rgb" <rbielaws@i1.net> writes:

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

`read' creates symbols (at read time).
`let' binds symbols to values (at evaluation time).

by the time `let' enters the picture, all the symbols that comprise the
form being evaluated have already been created.  they populate, along w/
other atoms like numbers and strings, the leaves of the nested lists in
memory (the form aka tree).

after `let' is done, the tree may or may not remain in memory.  like
anything else (in an emacs session), if nothing points to it, it will be
forgotten at some point.  however, the symbols are not forgotten unless
you explicitly evict them w/ `unintern'.

> Hopefully there are no more such flaws in my understanding.

there is hope indeed (but only by giving up this particular hope :-).
it's a good sign, in any case, when you question your assumptions and
broaden the inquiry.

probably a break from the symbols part in the elisp manual, while you
peruse the `let' or `read' parts, will help you formulate a better bug
report.

thi

Re: Mis-features of let

[Thien-Thi Nguyen]

"rgb" <rbielaws@i1.net> writes:

>>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* since the resulting behavior would apparently be
> undefined (as evidenced by the example in my previous post).
>
> Hence, a bug waiting to happen.

but it only waits for those who don't understand the computation model,
in which case, it is the return to understanding from mis-understanding
that is waiting to happen.  whether or not that is a bug depends on your
reliance on the (mis-)understood model.

here, you need to look into and grok a bit more on what precisely is a
symbol, and not just how it (or what you think of it) behaves in a
certain *scratch* buffer.  experimentation can show you the color of the
plant, but only in the light of the day.  the way to avoid the incessant
debate between pure theoreticians and pure empiricists is to synthesize
their approaches.  (if you do not wish to avoid it, that's fine, too.)

thi

Re: Defadvice use

[Barry Margolin]

In article <1113869741.838603.250620@o13g2000cwo.googlegroups.com>,
 "rgb" <rbielaws@i1.net> wrote:

> Stefan Monnier wrote:
> > > Doesn't (let (bookmark-bmenu-other-window) ...) have limited life.
> >
> >   (let (bookmark-bmenu-other-window) ...)
> >
> > only affects the bookmark-bmenu-other-window *variable*, not the
> > bookmark-bmenu-other-window function.
> >
> 
> If that isn't a bug waiting to happen I don't know what is.
> You appear to be asserting that it's documented to work that
> way but I'd counter with 2 arguments.
> 
> 1.  The `feature' is only _implied_, not documented.  There is
>     no mention in any Elisp manual section that covers plists
>     or symbol function cells about this behavior.

The Elisp manual specifically says that 'let' binds variables.  That's 
all it does.  Does it have to explicitly say all the things it *doesn't* 
do, like binding functions and property lists?  Function and variable 
bindings of symbols are totally independent.

If you want to bind a function, you can (require 'cl) and then use 
'flet'.

> 
> 2.  The `feature' invalidates much of the documented behavior of
>     symbols unless you know how the symbol was created.
> 
> Look at this:
> 
> (defun test1 ()
>   (let (a01)
>     (put 'a01 'hold "this")
>     (symbol-plist 'a01)))
> 
> (put 'a01 'hold "that") ; insure symbol already exists
> (symbol-plist 'a01)
>  => (hold "that")       ; value is there as expected
> 
> (test1)
>  => (hold "this")
> 
> (symbol-plist 'a01)
>  => (hold "this")       ; external value unexpectedly changed
> 
> (unintern "a01")        ; insure it doesn't exist
> (symbol-plist 'a01)
>  => nil                 ; no error.
> 
> (test1)
>  => (hold "this")
> 
> (symbol-plist 'a01)    ; Given the external value should change
>  => nil                ; it now unexpectedly doesn't

You're looking at the plist of a different symbol.  test1 is still 
referencing the symbol that you uninterned.  When you then type 'a01 
later, you intern a new symbol, which is not the one whose plist is 
modified when you call test1.

> It's obviously impossible to easily create any function or
> macro that manipulates function or property cells unless you
> can guarantee none of the symbols are ever created by let.
> 
> Since it appears to be by design, I'd be terribly curious to
> see any archive of discussions concerning why this is
> appropriate behavior.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Defadvice use

[Stefan Monnier]

> I'm trying to use an advice around the function; the advice providing
> a binding of the symbol `read-minibuffer' to the definition of
> `my-read-minibuffer'. Like the following:

> (defadvice la-fonction
>   (around la-fonction-extended enable compile)
>   "Documentation"
>    (let (f1)
>      (fset 'f1 read-minibuffer)
>      (fset 'read-minibuffer my-read-minibuffer)
>      ad-do-it
>      (fset 'read-minibuffer f1)))

> Any comment? Is it silly? Is there a better way? Any idea?

The last fset will not be executed if the ad-do-it signals an error (or is
interrupted with C-g, ...).  To protect against such eventualities, you want
to use unwind-protect.

An alternative is to use (require 'cl) and then

   (defadvice la-fonction
     (around la-fonction-extended enable compile)
     "Documentation"
     (flet ((read-minibuffer my-read-minibuffer))
       ad-do-it))

it does the same as what you did (except it uses unwind-protect), tho.
In general, I don't think there's a better way.  I would argue that if you
need to use such an ugly hack, you should only be morally allowed to do that
after sending a patch that will make it unnecessary in the future.

I.e. please try and send a patch that makes this hack unnecessary.
You can then use this hack, knowing that it's only a temporary workaround
until your patch is accepted and/or in widespread use.


        Stefan

Re: Defadvice use

[Matthias]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:

Thanks for your indication.

> (...) In general, I don't think there's a better way. I would argue
> that if you need to use such an ugly hack, you should only be
> morally allowed to do that after sending a patch that will make it
> unnecessary in the future.

You're true.

I am working on `dired-do-shell-command' and alike
commands (defined in Dired and Dired-X): I'd like them to be
completion compliant via the useful library Shell Command from
Masatoshi Tsuchiya.

The doc spec of `dired-read-shell-command' says `This is an extra
function so that you can redefine it, e.g., to use gmhist.' Dired-X do
this: it redefines the command using `defun'. I feel like it's very
ugly... But my knowledge in elisp is somewhat limited: I am not an
esthète!

So, I question now: Do you recommend that my patch change this (one
could use a variable containing the name of a function...)?
-- 
Matthias

Re: Defadvice use

[Stefan Monnier]

> So, I question now: Do you recommend that my patch change this (one
> could use a variable containing the name of a function...)?

I'm not sure I understand the question.
I'd recommend you write a sample patch and send it to emacs-devel@gnu.org,
along with an explanation of why you think it's necessary (including your
particular use).  It'll be debated and will require revisions anyway, so no
need to make it perfect.

Rather than dired-read-shell-command I'd argue Emacs should provide
a read-shell-command, which could be used at many places.
The pcomplete library already provides most of the code for that.


        Stefan

Re: Defadvice use

[Kevin Rodgers]

Matthias wrote:
 > I have the following problem: How do I advice a function so that
 > within that function, the function `read-minibuffer' (for example)
 > calls the definition of another function, say `my-read-minibuffer'?
 >
 > I'm trying to use an advice around the function; the advice providing
 > a binding of the symbol `read-minibuffer' to the definition of
 > `my-read-minibuffer'. Like the following:
 >
 > (defadvice la-fonction
 >   (around la-fonction-extended enable compile)
 >   "Documentation"
 >    (let (f1)
 >      (fset 'f1 read-minibuffer)
 >      (fset 'read-minibuffer my-read-minibuffer)
 >      ad-do-it
 >      (fset 'read-minibuffer f1)))
 >
 > Any comment? Is it silly? Is there a better way? Any idea?

Here's how I'd do it:

(defvar la-fonction-read-minibuffer nil
   "If non-nil, the function to call instead of `read-minibuffer'.")

(defadvice read-minibuffer (around la-fonction activate)
   "If `la-fonction-read-minibuffer' is non-nil, call it and return its 
result
instead."
   (if la-fonction-read-minibuffer
       (apply la-fonction-read-minibuffer (ad-get-args 0))
     ad-do-it))

(defadvice la-fonction (around read-minibuffer activate)
   "Temporarily bind `la-fonction-read-minibuffer' to `my-read-minibuffer'."
   (let ((la-fonction-read-minibuffer 'my-read-minibuffer))
     ad-do-it))

-- 
Kevin Rodgers