GNU bug report logs - #411
23.0.60; flet and byte-compilation

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 411 in the body.
You can then email your comments to 411 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; flet and byte-compilation
Date: Sat, 14 Jun 2008 17:17:12 +0200

A much simplified version of the original problem, but still a bug:

Create a file test.el with the following contents:

(defun f (x y)
  (flet ((+ (a b) (- a b)))
    (+ x y)))

Bytecompile it and load f.elc.

Evaluate the expression (f 1 2). This should yield -1, but the result
will be 3.



In GNU Emacs 23.0.60.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2008-05-17 on debian
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: C
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Help

Minor modes in effect:
  hl-line-mode: t
  minibuffer-indicate-depth-mode: t
  shell-dirtrack-mode: t
  display-time-mode: t
  msb-mode: t
  mouse-sel-mode: t
  icomplete-mode: t
  show-paren-mode: t
  recentf-mode: t
  auto-image-file-mode: t
  partial-completion-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  view-mode: t

Message #8 received at 411 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 411 <at> debbugs.gnu.org
Subject: Re: bug#411: 23.0.60; flet and byte-compilation
Date: Mon, 15 Sep 2008 04:04:58 -0400

Michael Heerdegen wrote:

> (defun f (x y)
>   (flet ((+ (a b) (- a b)))
>     (+ x y)))
> 
> Bytecompile it [...]
> 
> Evaluate the expression (f 1 2). This should yield -1, but the result
> will be 3.

Some (much delayed) observations:

1) it works to use `labels' instead of `flet'

2) it works to comment out the line in bytecomp.el

(byte-defop-compiler (+ byte-plus)  byte-compile-associative)

I guess byte-compile-associative mangles the '(+ x y) form without
regard for the redefinition in effect. I don't know if that is
fixable, or should be a documented caveat with regards to primitives.

Message #13 received at 411 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier  <monnier <at> iro.umontreal.ca>
Cc: Glenn Morris <rgm <at> gnu.org>, 411 <at> debbugs.gnu.org
Subject: Re: bug#411: 23.0.60; flet and byte-compilation
Date: Wed, 24 Sep 2008 22:16:07 -0400

Glenn Morris <rgm <at> gnu.org> wrote:

> > (defun f (x y)
> >   (flet ((+ (a b) (- a b)))
> >     (+ x y)))
> > 
> > Bytecompile it [...]
> > 
> > Evaluate the expression (f 1 2). This should yield -1, but the result
> > will be 3.
>
> it works to comment out the line in bytecomp.el
>
> (byte-defop-compiler (+ byte-plus)  byte-compile-associative)
>
> I guess byte-compile-associative mangles the '(+ x y) form without
> regard for the redefinition in effect. I don't know if that is
> fixable, or should be a documented caveat with regards to primitives.

I don't see how to fix this, and my inclination is to just document this
limitation in the docstring of `flet'.  Stefan, WDYT?

Message #18 received at 411 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Richard M. Stallman" <rms <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>, 411 <at> debbugs.gnu.org
Cc: monnier <at> iro.umontreal.ca
Subject: Re: bug#411: 23.0.60; flet and byte-compilation
Date: Thu, 25 Sep 2008 13:45:47 -0400

    > I guess byte-compile-associative mangles the '(+ x y) form without
    > regard for the redefinition in effect. I don't know if that is
    > fixable, or should be a documented caveat with regards to primitives.

    I don't see how to fix this, and my inclination is to just document this
    limitation in the docstring of `flet'.  Stefan, WDYT?

I am not sure if it is worth fixing, but one possible way
One possible way to fix it is to make the byte compiler check
that the function has a subr definition as usual.

Message #21 received at 411 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: rms <at> gnu.org
Cc: 411 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>
Subject: Re: bug#411: 23.0.60; flet and byte-compilation
Date: Fri, 26 Sep 2008 14:48:46 -0400

"Richard M. Stallman" wrote:

> One possible way to fix it is to make the byte compiler check
> that the function has a subr definition as usual.

When I tried to do this naively in byte-compile-associative, it did
not work, because the compiler does not evaluate the (fset '+ ...)
redefinition at compile-time.

Perhaps flet need a byte-compiler handler that looks at the functions
being bound in the flet, and temporarily (while the flet body is being
compiled) removes any special byte-compile properties they might have.

Message #24 received at 411 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 411 <at> debbugs.gnu.org
Cc: rms <at> gnu.org, Chong Yidong <cyd <at> stupidchicken.com>
Subject: Re: bug#411: 23.0.60; flet and byte-compilation
Date: Sun, 19 Oct 2008 21:05:31 -0400

Glenn Morris wrote:

> Perhaps flet need a byte-compiler handler that looks at the functions
> being bound in the flet, and temporarily (while the flet body is being
> compiled) removes any special byte-compile properties they might have.

The problem with this is that there doesn't seem to be a way to
specify byte-compile handlers for macros (except macros at top-level).
The compile functions always just call `macroexpand' before doing
anything else.

Message #27 received at 411 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 411 <at> debbugs.gnu.org
Cc: Chong Yidong <cyd <at> stupidchicken.com>, rms <at> gnu.org
Subject: Re: bug#411: 23.0.60; flet and byte-compilation
Date: Wed, 22 Oct 2008 22:41:24 -0400

severity 411 wishlist
stop

Well, I can't make it work, so I have made such things throw an error
when byte-compiled. I am leaving making it work open as a wishlist item.

Message #34 received at 411-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 411-done <at> debbugs.gnu.org
Subject: Re: bug#411: 23.0.60; flet and byte-compilation
Date: Tue, 30 Oct 2012 23:56:06 -0400

Version: 24.3

It seems to work (somehow) with the new hotness cl-lib and cl-flet
rather than the old and busted cl and flet.

Message #37 received at 411 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 411 <at> debbugs.gnu.org
Cc: rgm <at> gnu.org
Subject: Re: bug#411: 23.0.60; flet and byte-compilation
Date: Wed, 31 Oct 2012 09:58:07 -0400

> It seems to work (somehow) with the new hotness cl-lib and cl-flet
> rather than the old and busted cl and flet.

Indeed, because `cl-flet' is a different beast, much more like `labels'
than like CL's `flet' (it is lexically scoped).


        Stefan

Message #40 received at 411 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>, <411 <at> debbugs.gnu.org>
Subject: RE: bug#411: 23.0.60; flet and byte-compilation
Date: Wed, 31 Oct 2012 08:01:59 -0700

> Indeed, because `cl-flet' is a different beast, much more 
> like `labels' than like CL's `flet' (it is lexically scoped).

Just out of curiosity (and I haven't followed this thread), why?

Why make `cl-flet' less like CL's `flet'?  If you want `labels'-like behavior,
why not define `cl-labels' for that?

Or call this `foobar' or whatever.  Calling it `cl-flet' seems the more
misleading the farther the behavior gets from CL's `flet' - no?

Sounds like this is a step backward - in terms of possible confusion, at least.
 

Message #43 received at 411 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 411 <at> debbugs.gnu.org
Subject: Re: bug#411: 23.0.60; flet and byte-compilation
Date: Wed, 31 Oct 2012 12:06:39 -0400

>> Indeed, because `cl-flet' is a different beast, much more
>> like `labels' than like CL's `flet' (it is lexically scoped).
> Just out of curiosity (and I haven't followed this thread), why?

Because:
- CL's `flet' is completely unlike Common-Lisp's `flet'.
- CL's `flet' is more like defadvice, except (dynamically) scoped and
  without adjusting the docstring to at least mention that something
  fishy is going on.
IOW because CL's `flet' does something we generally want to discourage.
Or rather, because CL's `flet' was a mistake, hence its being
marked obsolete.
  
> Or call this `foobar' or whatever.  Calling it `cl-flet' seems the more
> misleading the farther the behavior gets from CL's `flet' - no?

`cl-flet' is a (hopefully) faithful implementation of Common-Lisp's
`flet', so I think it deserves its name.


        Stefan

Message #46 received at 411 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 411 <at> debbugs.gnu.org
Subject: RE: bug#411: 23.0.60; flet and byte-compilation
Date: Wed, 31 Oct 2012 09:13:00 -0700

> `cl-flet' is a (hopefully) faithful implementation of Common-Lisp's
> `flet', so I think it deserves its name.

Sorry, I misunderstood your references to "CL" to mean Common Lisp itself,
rather than the cl.el stuff.  Sorry for the noise.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.