bug#411: 23.0.60; flet and byte-compilation

bug#411: 23.0.60; flet and byte-compilation

[Michael Heerdegen]

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

bug#411: 23.0.60; flet and byte-compilation

[Glenn Morris]

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.

bug#411: 23.0.60; flet and byte-compilation

[Chong Yidong]

Glenn Morris <rgm@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?

bug#411: 23.0.60; flet and byte-compilation

[Richard M. Stallman]

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

bug#411: 23.0.60; flet and byte-compilation

[Glenn Morris]

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

bug#411: 23.0.60; flet and byte-compilation

[Glenn Morris]

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.

bug#411: 23.0.60; flet and byte-compilation

[Glenn Morris]

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.

bug#411: 23.0.60; flet and byte-compilation

[Glenn Morris]

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.

bug#411: 23.0.60; flet and byte-compilation

[Stefan Monnier]

> 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

bug#411: 23.0.60; flet and byte-compilation

[Drew Adams]

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

bug#411: 23.0.60; flet and byte-compilation

[Stefan Monnier]

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

bug#411: 23.0.60; flet and byte-compilation

[Drew Adams]

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