problems with flet on last emacs

problems with flet on last emacs

[Thierry Volpiatto]

Hi,
stranges things happen with recent Emacs.
All functions that use flet don't work anymore.
The anonymous function defined by the flet is not read.
(i.e void function foo)
I could make it working by restarting my computer, recompiling
some libraries, (helm, slime) and it worked.
When I recompile files, restart Emacs, the problem occur again.
I have not this problem on 24.1.

Any ideas?
If not I will send a bug report.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: problems with flet on last emacs

[Pascal J. Bourguignon]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Hi,
> stranges things happen with recent Emacs.
> All functions that use flet don't work anymore.
> The anonymous function defined by the flet is not read.
> (i.e void function foo)
> I could make it working by restarting my computer, recompiling
> some libraries, (helm, slime) and it worked.
> When I recompile files, restart Emacs, the problem occur again.
> I have not this problem on 24.1.
>
> Any ideas?
> If not I will send a bug report.

flet is a macro in cl-macs.el
in emacs-version "23.4.2":

(pp (macroexpand '(flet ((f (x) (+ x x)))
                      (f 42))))

(let*
    ((#1=#:--cl-letf-bound--
      (fboundp #2='f))
     (#3=#:--cl-letf-save--
      (and #1#
           (symbol-function #2#))))
  (unwind-protect
       (progn
         (fset #2#
               (function*
                (lambda
                    (x)
                 (block f
                   (+ x x)))))
         (f 42))
    (if #1#
        (fset #2# #3#)
        (fmakunbound #2#))))

This is spooky, because it rebinds the function slot of the symbol
(globally).  In Common Lisp, flet is a lexical binding.

An alternative (and more correct) implementation of flet would use a
code walker to substitute any call to (f 42) by something like:
(--cl-letf-function-- 42).


To avoid problem with the current version of flet, you should use a
function name that is not the name of a global function.

For example:

    (defun pjb--do-something ()
      (flet ((pjb--do-something--inner-fun (x) (+ x x)))
        (pjb--do-something--inner-fun 42)))


If you use a simple name, such as string-compare, (there's no
string-compare function in this emacs 23.4.2 instance), then it may
break when you load some library that define that function, or when you
switch to another version of emacs that define that function.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: problems with flet on last emacs

[Stefan Monnier]

>> stranges things happen with recent Emacs.
>> All functions that use flet don't work anymore.

And I hopefully have fixed this about half an hour ago.

> flet is a macro in cl-macs.el
> in emacs-version "23.4.2":
[...]
> This is spooky, because it rebinds the function slot of the symbol
> (globally).

Yes, it's pretty ugly.

> In Common Lisp, flet is a lexical binding.
> An alternative (and more correct) implementation of flet would use a
> code walker to substitute any call to (f 42) by something like:
> (--cl-letf-function-- 42).

`cl-flet' does something sane along these lines, which should be
compliant with the Common-Lisp semantics.


        Stefan

Re: problems with flet on last emacs

[Thierry Volpiatto]

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

>
> And I hopefully have fixed this about half an hour ago.
Seem fixed, thanks.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: problems with flet on last emacs

[Ivan Kanis]

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

>>> stranges things happen with recent Emacs.
>>> All functions that use flet don't work anymore.
>
> And I hopefully have fixed this about half an hour ago.

I saw problems this problem when I compiled slime yesterday. Today's
build didn't fix slime contrib directory:

slime-repl.el:129:1:Error: (slime-connection-output-buffer) is not a valid place expression

I tried looking at it but it goes through multiple macro expansion and
quite frankly it's getting over my head.

Take care,
-- 
Ivan

Let a fool hold his tongue and he will pass for a sage.
    -- Publilius Syrus

Re: problems with flet on last emacs

[Thierry Volpiatto]

Ivan Kanis <ivan.kanis@googlemail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>>>> stranges things happen with recent Emacs.
>>>> All functions that use flet don't work anymore.
>>
>> And I hopefully have fixed this about half an hour ago.
>
> I saw problems this problem when I compiled slime yesterday. Today's
> build didn't fix slime contrib directory:
>
> slime-repl.el:129:1:Error: (slime-connection-output-buffer) is not a valid place expression
>
> I tried looking at it but it goes through multiple macro expansion and
> quite frankly it's getting over my head.
Try to recompile contrib directory and slime.el.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: problems with flet on last emacs

[Ivan Kanis]

Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote:

> Ivan Kanis <ivan.kanis@googlemail.com> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>
>>>>> stranges things happen with recent Emacs.
>>>>> All functions that use flet don't work anymore.
>>>
>>> And I hopefully have fixed this about half an hour ago.
>>
>> I tried looking at it but it goes through multiple macro expansion and
>> quite frankly it's getting over my head.
>
> Try to recompile contrib directory and slime.el.

I did. I just tried again just to make sure. Here is the error plus the
warnings:

In toplevel form:
slime-repl.el:18:23:Warning: `:authors' called as a function
slime-repl.el:27:4:Warning: `:license' called as a function
slime-repl.el:28:4:Warning: `:on-load' called as a function
slime-repl.el:31:10:Warning: `:on-unload' called as a function
slime-repl.el:32:16:Warning: `:swank-dependencies' called as a function
slime-repl.el:129:1:Error: (slime-connection-output-buffer) is not a valid place expression
make: *** [/home/ivan/.emacs.d-bzr/slime/slime-repl.elc] Error 1
-- 
Ivan Kanis
http://ivan.kanis.fr

Parting is all we know of heaven, And all we need of hell.
    -- Emily Dickinson

Re: problems with flet on last emacs

[Thierry Volpiatto]

Ivan Kanis <ivan.kanis@googlemail.com> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote:
>
>> Ivan Kanis <ivan.kanis@googlemail.com> writes:
>>
>>> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>
>>>>>> stranges things happen with recent Emacs.
>>>>>> All functions that use flet don't work anymore.
>>>>
>>>> And I hopefully have fixed this about half an hour ago.
>>>
>>> I tried looking at it but it goes through multiple macro expansion and
>>> quite frankly it's getting over my head.
>>
>> Try to recompile contrib directory and slime.el.
>
> I did. I just tried again just to make sure. Here is the error plus the
> warnings:
>
> In toplevel form:
> slime-repl.el:18:23:Warning: `:authors' called as a function
> slime-repl.el:27:4:Warning: `:license' called as a function
> slime-repl.el:28:4:Warning: `:on-load' called as a function
> slime-repl.el:31:10:Warning: `:on-unload' called as a function
> slime-repl.el:32:16:Warning: `:swank-dependencies' called as a function
> slime-repl.el:129:1:Error: (slime-connection-output-buffer) is not a valid place expression
> make: *** [/home/ivan/.emacs.d-bzr/slime/slime-repl.elc] Error 1

So maybe try removing all ".elc" and restart emacs.
It is working here not compiled on both version 24.1 and trunk version.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: problems with flet on last emacs

[Ivan Kanis]

Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote:

> Ivan Kanis <ivan.kanis@googlemail.com> writes:
>
>> Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote:
>>
>>> Ivan Kanis <ivan.kanis@googlemail.com> writes:
>>>
>>>> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>>
>>>>>>> stranges things happen with recent Emacs.
>>>>>>> All functions that use flet don't work anymore.
>>>>>
>>>>> And I hopefully have fixed this about half an hour ago.
>>>>
>>>> I tried looking at it but it goes through multiple macro expansion and
>>>> quite frankly it's getting over my head.
>>>
>>> Try to recompile contrib directory and slime.el.
>>
>> I did. I just tried again just to make sure. Here is the error plus the
>> warnings:
>>
>> In toplevel form:
>> slime-repl.el:18:23:Warning: `:authors' called as a function
>> slime-repl.el:27:4:Warning: `:license' called as a function
>> slime-repl.el:28:4:Warning: `:on-load' called as a function
>> slime-repl.el:31:10:Warning: `:on-unload' called as a function
>> slime-repl.el:32:16:Warning: `:swank-dependencies' called as a function
>> slime-repl.el:129:1:Error: (slime-connection-output-buffer) is not a
>> valid place expression
>> make: *** [/home/ivan/.emacs.d-bzr/slime/slime-repl.elc] Error 1
>
> So maybe try removing all ".elc" and restart emacs.
> It is working here not compiled on both version 24.1 and trunk version.

Thanks for the advice, I am just switching back to 24.1 till the dust
settles ;)
-- 
Ivan Kanis
http://ivan.kanis.fr

Sure, ninety percent of science fiction is crud. That's because ninety
percent of everything is crud.
    -- Theodore Sturgeon

I am listening to "Talking Heads - Take Me to the River".

Re: problems with flet on last emacs

[Stefan Monnier]

> Thanks for the advice, I am just switching back to 24.1 till the dust
> settles ;)

There's no known bugs in that area (other than yours), so "the dust has
settled already".  You might want to investigate a bit more, e.g. give
us a reproducible test case.


        Stefan

Re: problems with flet on last emacs

[Ivan Kanis]

Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

>> Thanks for the advice, I am just switching back to 24.1 till the dust
>> settles ;)
>
> There's no known bugs in that area (other than yours), so "the dust has
> settled already".  You might want to investigate a bit more, e.g. give
> us a reproducible test case.

Fair enough I can't reproduce it. Thanks to your help with #11821 I can
compile slime again with bzr emacs.
-- 
Ivan Kanis
http://ivan.kanis.fr

I feel like a million tonight -  but one at a time.
    -- Mae West

I am listening to "Dead Can Dance - The Snake And The Moon".

Re: problems with flet on last emacs

[João Távora]

(Sorry to revive this ancient thread, maybe this is discussed in
another thread.)

Is `flet` (not cl-flet) going to be available in future emacsen? Or
should I start future-proofing my code with compatibility macros? What
about `labels` and other common-lisp macros and defuns? This recently
came about in yasnippet, see
https://github.com/capitaomorte/yasnippet/pull/330.

On Thu, Jul 12, 2012 at 5:44 PM, Ivan Kanis <ivan.kanis@googlemail.com> wrote:
> Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:
>
>>> Thanks for the advice, I am just switching back to 24.1 till the dust
>>> settles ;)
>>
>> There's no known bugs in that area (other than yours), so "the dust has
>> settled already".  You might want to investigate a bit more, e.g. give
>> us a reproducible test case.
>
> Fair enough I can't reproduce it. Thanks to your help with #11821 I can
> compile slime again with bzr emacs.
> --
> Ivan Kanis
> http://ivan.kanis.fr
>
> I feel like a million tonight -  but one at a time.
>     -- Mae West
>
> I am listening to "Dead Can Dance - The Snake And The Moon".
>



-- 
João Távora

Re: problems with flet on last emacs

[Stefan Monnier]

> Is `flet` (not cl-flet) going to be available in future emacsen?

Depends how "future" those emacsen are.  And also depends on how the
future turns out to be.  In my ideal future, those CL thingies not
prefixed by "cl-" will indeed disappear.  But given the enormous amount
of packages out there that use (require 'cl), this future is still
many years away.

And when cl.el gets dropped from Emacs, it'll probably be moved to GNU
ELPA.  Similarly, a forward-compatiblity cl-lib.el may appear on ELPA
(hopefully earlier) for Emacs<24.3, so that packages can move to cl-lib
without restricting themselves to Emacs-24.3 and up.

> Or should I start future-proofing my code with compatibility macros?

You could help write the cl-lib.el forward-compatibility package.

> What about `labels` and other common-lisp macros and defuns?

`flet' is special in that it was a weird beast using an ugly
implementation.  So while all of cl.el will be marked obsolete (i.e. not
yet removed) at some point (maybe for Emacs-25?), `flet' (along with
a couple others) is already marked obsolete.

Of course, I recommend you use cl-flet, cl-flet*, or cl-labels, but if
you don't want to limit yourself to emacs>24.2 you can use
`labels' instead.

These have the advantage that the function definitions are lexically
scoped, contrary to `flet' which ends up having the same kind of
problems as `defadvice' but without saying so.


        Stefan

Re: problems with flet on last emacs

[João Távora]

On Fri, Nov 9, 2012 at 7:23 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> ELPA.  Similarly, a forward-compatiblity cl-lib.el may appear on ELPA

Aha cl-lib.el, ok, ok could be worse... I'd thought of adding my own
to yasnippet, but this is nicer of course.

> You could help write the cl-lib.el forward-compatibility package.

Could, but not likely. I've barely time to fix yasnippet bugs, I'd
rather forward this to Roland Walker, who's been contributing the
yasnippet compatibility fixes. He might want to help, just have to ask
his email, is he on this list?

>> What about `labels` and other common-lisp macros and defuns?
>
> `flet' is special in that it was a weird beast

Agree. But don't forget that some of the weirdness might be in
use by libraries. Yasnippet, as I inherited it, uses that dynamically
and globablly fsetting behaviour to mock functions. Not a big deal to
change, but there might be other libraries that do.

So to summarize: there is going to be a forward compat lib, 'labels'
and 'dolist' and 'mapcar' and such are still valid for some time to
come. 'flet' is going away now, and 'cl-flet' will provide the same
weird behaviour with a nicer implementation.

Thanks!
João

Re: problems with flet on last emacs

[Stefan Monnier]

> Agree. But don't forget that some of the weirdness might be in
> use by libraries.

I know.  And they'll have to change, e.g. using defadvice.

> come. 'flet' is going away now, and 'cl-flet' will provide the same
> weird behaviour with a nicer implementation.

No, cl-flet is like Common-Lisp's `flet', i.e. lexically scoped, like
`labels', but without the mutual-recursion.  If you want the "function
redefinition" behavior, you need defadvice.


        Stefan

Re: problems with flet on last emacs

[João Távora]

On Sat, Nov 10, 2012 at 10:46 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> No, cl-flet is like Common-Lisp's `flet', i.e. lexically scoped, like
> `labels', but without the mutual-recursion.  If you want the "function
> redefinition" behavior, you need defadvice.

Hmmm, OK, good to know that then, but 'defadvice' feels strange,
what's the problem
with using  a combo of 'fset', 'symbol-function' and 'unwind-protect'?
Something like

(defun foo ()
  (message "foo"))

(defun meta-foo ()
  (foo))

(let ((saved (symbol-function 'foo)))
  (unwind-protect
      (progn
        (fset 'foo #'(lambda ()
                       (message "bar!")))
        (meta-foo))
    (fset 'foo saved)))

--
João Távora

Re: problems with flet on last emacs

[Stefan Monnier]

> (let ((saved (symbol-function 'foo)))
>   (unwind-protect
>       (progn
>         (fset 'foo #'(lambda ()
>                        (message "bar!")))
>         (meta-foo))
>     (fset 'foo saved)))

Same problem as with flet: the redefinition is hard to find, dynamically
scoped, etc...

Better use

   (defvar foo-bar nil)
   (defadvice foo (around blabla activate)
     (if foo-bar (message "bar!") ad-do-it))

and then

   ...
   (let ((foo-bar t))
     ...)

So C-h f foo RET will tell you about the redefinition and you can
recover the non-redefined behavior with a simple (setq foo-bar nil).


        Stefan

Re: problems with flet on last emacs

[Andreas Röhler]

Am 11.11.2012 00:38, schrieb Stefan Monnier:
>> (let ((saved (symbol-function 'foo)))
>>    (unwind-protect
>>        (progn
>>          (fset 'foo #'(lambda ()
>>                         (message "bar!")))
>>          (meta-foo))
>>      (fset 'foo saved)))
>
> Same problem as with flet: the redefinition is hard to find, dynamically
> scoped, etc...
>
> Better use
>
>     (defvar foo-bar nil)
>     (defadvice foo (around blabla activate)
>       (if foo-bar (message "bar!") ad-do-it))
>
> and then
>
>     ...
>     (let ((foo-bar t))
>       ...)
>
> So C-h f foo RET will tell you about the redefinition and you can
> recover the non-redefined behavior with a simple (setq foo-bar nil).
>
>
>          Stefan
>
>

Hi Stefan,

while looking with interest and delight at new features, what about make for that process a similar change as was made with bug-tracking.
IMO the decision-making process might be done in a more structured way than now - by keeping the final instances.

Best,

Andreas

Re: problems with flet on last emacs

[Tassilo Horn]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> All functions that use flet don't work anymore.
> The anonymous function defined by the flet is not read.
> (i.e void function foo)

Oh, yes, that occured to me too.

> I could make it working by restarting my computer, recompiling
> some libraries, (helm, slime) and it worked.

Not for me.  I've tried to rebuild every elisp package, but the error
persists.

> When I recompile files, restart Emacs, the problem occur again.
> I have not this problem on 24.1.

Ditto, currently I'm running the released version without problems.

> Any ideas?
> If not I will send a bug report.

Please do so.  Here's a recipe:

  1. emacs -Q
  2. goto *scratch*
  3. eval

     (require 'cl)
     (flet ((foo () 1))
       (foo))


Debugger entered--Lisp error: (void-function foo)
  symbol-function(foo)
  (let* ((x (cl-function (lambda nil (cl-block foo 1)))) (x (symbol-function (quote foo)))) (unwind-protect (progn (fset (quote foo) x) (foo)) (fset (quote foo) x)))
  (letf* (((symbol-function (quote foo)) (cl-function (lambda nil (cl-block foo 1))))) (foo))
  (flet ((foo nil 1)) (foo))
  eval((flet ((foo nil 1)) (foo)) nil)
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)

The macroexpansion is a bit strange:

(let* ((x (cl-function (lambda nil (cl-block foo 1))))
       (x (symbol-function (quote foo))))
  (unwind-protect (progn
                    (fset (quote foo) x)
                    (foo))
    (fset (quote foo) x)))

Two times `x', and those should probably gensyms, anyway...

Bye,
Tassilo

Re: problems with flet on last emacs

[Thierry Volpiatto]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> All functions that use flet don't work anymore.
>> The anonymous function defined by the flet is not read.
>> (i.e void function foo)
>
> Oh, yes, that occured to me too.
>
>> I could make it working by restarting my computer, recompiling
>> some libraries, (helm, slime) and it worked.
>
> Not for me.  I've tried to rebuild every elisp package, but the error
> persists.
>
>> When I recompile files, restart Emacs, the problem occur again.
>> I have not this problem on 24.1.
>
> Ditto, currently I'm running the released version without problems.
>
>> Any ideas?
>> If not I will send a bug report.
>
> Please do so.  Here's a recipe:
>
>   1. emacs -Q
>   2. goto *scratch*
>   3. eval
>
>      (require 'cl)
>      (flet ((foo () 1))
>        (foo))
>
>
> Debugger entered--Lisp error: (void-function foo)

I can confirm that, of current-release (24.1) it return 1 as expected.

> The macroexpansion is a bit strange:
>
> (let* ((x (cl-function (lambda nil (cl-block foo 1))))
>        (x (symbol-function (quote foo))))
>   (unwind-protect (progn
>                     (fset (quote foo) x)
>                     (foo))
>     (fset (quote foo) x)))
>
> Two times `x', and those should probably gensyms, anyway...
>
> Bye,
> Tassilo

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: problems with flet on last emacs

[Thierry Volpiatto]

Tassilo Horn <tassilo@member.fsf.org> writes:

> The macroexpansion is a bit strange:
>
> (let* ((x (cl-function (lambda nil (cl-block foo 1))))
>        (x (symbol-function (quote foo))))
>   (unwind-protect (progn
>                     (fset (quote foo) x)
>                     (foo))
>     (fset (quote foo) x)))
>
> Two times `x', and those should probably gensyms, anyway...

Here the forms returned by the two different Emacs versions:

--8<---------------cut here---------------start------------->8---
(require 'cl)
(macroexpand '(flet ((foo (a) (+ a 1))) (foo 2)))

;; 24.1
(let* ((--cl-letf-bound-- (fboundp (quote foo)))
       (--cl-letf-save-- (and --cl-letf-bound-- (symbol-function (quote foo)))))
  (unwind-protect
       (progn (fset (quote foo)
                    (function* (lambda (a) (block foo (+ a 1))))) (foo 2))
    (if --cl-letf-bound--
        (fset (quote foo) --cl-letf-save--)
        (fmakunbound (quote foo)))))

;; 24.1.50.1
(let* ((x (cl-function (lambda (a) (cl-block foo (+ a 1)))))
       (x (symbol-function (quote foo))))
  (unwind-protect
       (progn
         (fset (quote foo) x) (foo 2))
    (fset (quote foo) x)))
--8<---------------cut here---------------end--------------->8---

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: problems with flet on last emacs

[Pascal J. Bourguignon]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> All functions that use flet don't work anymore.
>> The anonymous function defined by the flet is not read.
>> (i.e void function foo)
>
> Oh, yes, that occured to me too.
>
>> I could make it working by restarting my computer, recompiling
>> some libraries, (helm, slime) and it worked.
>
> Not for me.  I've tried to rebuild every elisp package, but the error
> persists.
>
>> When I recompile files, restart Emacs, the problem occur again.
>> I have not this problem on 24.1.
>
> Ditto, currently I'm running the released version without problems.
>
>> Any ideas?
>> If not I will send a bug report.
>
> Please do so.  Here's a recipe:
>
>   1. emacs -Q
>   2. goto *scratch*
>   3. eval
>
>      (require 'cl)
>      (flet ((foo () 1))
>        (foo))
>
>
> Debugger entered--Lisp error: (void-function foo)
>   symbol-function(foo)
>   (let* ((x (cl-function (lambda nil (cl-block foo 1)))) (x (symbol-function (quote foo)))) (unwind-protect (progn (fset (quote foo) x) (foo)) (fset (quote foo) x)))
>   (letf* (((symbol-function (quote foo)) (cl-function (lambda nil (cl-block foo 1))))) (foo))
>   (flet ((foo nil 1)) (foo))
>   eval((flet ((foo nil 1)) (foo)) nil)
>   eval-last-sexp-1(nil)
>   eval-last-sexp(nil)
>   call-interactively(eval-last-sexp nil nil)
>
> The macroexpansion is a bit strange:

Yes, it doesn't seem to be guarding for unfbound symbols…

> (let* ((x (cl-function (lambda nil (cl-block foo 1))))
>        (x (symbol-function (quote foo))))
>   (unwind-protect (progn
>                     (fset (quote foo) x)
>                     (foo))
>     (fset (quote foo) x)))
>
> Two times `x', and those should probably gensyms, anyway...

They probably are.

Try:

(eq 'x (first (first (second (macroexpand '(flet ((foo () 1))
                                              (foo)))))))

and try:

(let ((expansion  (macroexpand '(flet ((foo () 1)) (foo)))))
  (eq (first (first  (second expansion)))
      (first (second (second expansion)))))



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: problems with flet on last emacs

[Tassilo Horn]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

>> Two times `x', and those should probably gensyms, anyway...
>
> They probably are.
>
> Try:
>
> (eq 'x (first (first (second (macroexpand '(flet ((foo () 1))
>                                               (foo)))))))
> and try:
>
> (let ((expansion  (macroexpand '(flet ((foo () 1)) (foo)))))
>   (eq (first (first  (second expansion)))
>       (first (second (second expansion)))))

Ok, both are nil, so x and x are different symbols.  cl uses macroexp's
macro expansion macros at various places, and `macroexp-let2' uses
(make-symbol "x") to create new symbols.  That's not making it easier to
understand...

Bye,
Tassilo

Re: problems with flet on last emacs

[Pascal J. Bourguignon]

Tassilo Horn <tassilo@member.fsf.org> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>
>>> Two times `x', and those should probably gensyms, anyway...
>>
>> They probably are.
>>
>> Try:
>>
>> (eq 'x (first (first (second (macroexpand '(flet ((foo () 1))
>>                                               (foo)))))))
>> and try:
>>
>> (let ((expansion  (macroexpand '(flet ((foo () 1)) (foo)))))
>>   (eq (first (first  (second expansion)))
>>       (first (second (second expansion)))))
>
> Ok, both are nil, so x and x are different symbols.  cl uses macroexp's
> macro expansion macros at various places, and `macroexp-let2' uses
> (make-symbol "x") to create new symbols.  That's not making it easier to
> understand...

That'd be a "bug" in the emacs lisp printer.


Symbols that are not interned in any package should be printed with the
#: prefix.  eg. in emacs-version "23.4.2", (make-symbol "x") --> #:x

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: problems with flet on last emacs

[Tassilo Horn]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

>> Ok, both are nil, so x and x are different symbols.  cl uses macroexp's
>> macro expansion macros at various places, and `macroexp-let2' uses
>> (make-symbol "x") to create new symbols.  That's not making it easier to
>> understand...
>
> That'd be a "bug" in the emacs lisp printer.
>
>
> Symbols that are not interned in any package should be printed with
> the #: prefix.  eg. in emacs-version "23.4.2", (make-symbol "x") -->
> #:x

Are you sure you haven't set `print-gensym'?  If that's nil, it prints
just x here (Emacs 24.1).  And even then you can't distinguish #:x and
#:x just by looking at the expansion.  For that, you need
`print-circle', too.

Bye,
Tassilo

Re: problems with flet on last emacs

[Pascal J. Bourguignon]

Tassilo Horn <tassilo@member.fsf.org> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>
>>> Ok, both are nil, so x and x are different symbols.  cl uses macroexp's
>>> macro expansion macros at various places, and `macroexp-let2' uses
>>> (make-symbol "x") to create new symbols.  That's not making it easier to
>>> understand...
>>
>> That'd be a "bug" in the emacs lisp printer.
>>
>>
>> Symbols that are not interned in any package should be printed with
>> the #: prefix.  eg. in emacs-version "23.4.2", (make-symbol "x") -->
>> #:x
>
> Are you sure you haven't set `print-gensym'?  If that's nil, it prints
> just x here (Emacs 24.1).  And even then you can't distinguish #:x and
> #:x just by looking at the expansion.  For that, you need
> `print-circle', too.

Yes, but I've been using emacs for so long… I must have set those
variables in my ~/.emacs twenty years ago and forgotten about them.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: problems with flet on last emacs

[Andreas Schwab]

Tassilo Horn <tassilo@member.fsf.org> writes:

> The macroexpansion is a bit strange:
>
> (let* ((x (cl-function (lambda nil (cl-block foo 1))))
>        (x (symbol-function (quote foo))))
>   (unwind-protect (progn
>                     (fset (quote foo) x)
>                     (foo))
>     (fset (quote foo) x)))
>

I'm getting this:

(let* ((#1=#:x (cl-function (lambda nil (cl-block foo 1))))
       (#3=#:x (cl--symbol-function #2='foo)))
  (unwind-protect
      (progn
	(if (eq #1# . #4=('cl--unbound))
	    (fmakunbound #2#)
	  (fset #2# #1#))
	(foo))
    (if (eq #3# . #4#)
	(fmakunbound #2#)
      (fset #2# #3#))))

> Two times `x', and those should probably gensyms, anyway...

Which they are.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: problems with flet on last emacs

[Tassilo Horn]

Andreas Schwab <schwab@linux-m68k.org> writes:

> I'm getting this:
>
> (let* ((#1=#:x (cl-function (lambda nil (cl-block foo 1))))
>        (#3=#:x (cl--symbol-function #2='foo)))
>   (unwind-protect
>       (progn
> 	(if (eq #1# . #4=('cl--unbound))
> 	    (fmakunbound #2#)
> 	  (fset #2# #1#))
> 	(foo))
>     (if (eq #3# . #4#)
> 	(fmakunbound #2#)
>       (fset #2# #3#))))
>
>> Two times `x', and those should probably gensyms, anyway...
>
> Which they are.

Yes, now I've found `print-gensym' and `print-circle' myself. ;-)

Bye,
Tassilo

Re: problems with flet on last emacs

[Glenn Morris]

Thierry Volpiatto wrote:

> If not I will send a bug report.

Search for existing bugs with "flet" in the subject and find it is a known
problem, avoiding the need to repeat all the diagnosis:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11780