unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#411: 23.0.60; flet and byte-compilation
@ 2008-06-14 15:17 Michael Heerdegen
  0 siblings, 0 replies; 13+ messages in thread
From: Michael Heerdegen @ 2008-06-14 15:17 UTC (permalink / raw)
  To: emacs-pretest-bug

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






^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#411: 23.0.60; flet and byte-compilation
@ 2008-09-15  8:04 Glenn Morris
  0 siblings, 0 replies; 13+ messages in thread
From: Glenn Morris @ 2008-09-15  8:04 UTC (permalink / raw)
  To: 411

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.






^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#411: 23.0.60; flet and byte-compilation
@ 2008-09-25  2:16 Chong Yidong
  2008-09-25 17:45 ` Richard M. Stallman
  0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2008-09-25  2:16 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 411

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?






^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#411: 23.0.60; flet and byte-compilation
  2008-09-25  2:16 bug#411: 23.0.60; flet and byte-compilation Chong Yidong
@ 2008-09-25 17:45 ` Richard M. Stallman
  2008-09-26 18:48   ` Glenn Morris
  0 siblings, 1 reply; 13+ messages in thread
From: Richard M. Stallman @ 2008-09-25 17:45 UTC (permalink / raw)
  To: Chong Yidong, 411

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








^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#411: 23.0.60; flet and byte-compilation
  2008-09-25 17:45 ` Richard M. Stallman
@ 2008-09-26 18:48   ` Glenn Morris
  2008-10-20  1:05     ` Glenn Morris
  0 siblings, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2008-09-26 18:48 UTC (permalink / raw)
  To: rms; +Cc: 411, Chong Yidong

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






^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#411: 23.0.60; flet and byte-compilation
  2008-09-26 18:48   ` Glenn Morris
@ 2008-10-20  1:05     ` Glenn Morris
  2008-10-23  2:41       ` Glenn Morris
  0 siblings, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2008-10-20  1:05 UTC (permalink / raw)
  To: 411; +Cc: Chong Yidong, rms

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.






^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#411: 23.0.60; flet and byte-compilation
  2008-10-20  1:05     ` Glenn Morris
@ 2008-10-23  2:41       ` Glenn Morris
  2008-10-23  2:50         ` Processed: " Emacs bug Tracking System
  2012-10-31  3:56         ` Glenn Morris
  0 siblings, 2 replies; 13+ messages in thread
From: Glenn Morris @ 2008-10-23  2:41 UTC (permalink / raw)
  To: 411; +Cc: Chong Yidong, rms

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.






^ permalink raw reply	[flat|nested] 13+ messages in thread

* Processed: Re: bug#411: 23.0.60; flet and byte-compilation
  2008-10-23  2:41       ` Glenn Morris
@ 2008-10-23  2:50         ` Emacs bug Tracking System
  2012-10-31  3:56         ` Glenn Morris
  1 sibling, 0 replies; 13+ messages in thread
From: Emacs bug Tracking System @ 2008-10-23  2:50 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Emacs Bugs

Processing commands for control@emacsbugs.donarmstrong.com:

> severity 411 wishlist
bug#411: 23.0.60; flet and byte-compilation
Severity set to `wishlist' from `normal'

> stop
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#411: 23.0.60; flet and byte-compilation
  2008-10-23  2:41       ` Glenn Morris
  2008-10-23  2:50         ` Processed: " Emacs bug Tracking System
@ 2012-10-31  3:56         ` Glenn Morris
  2012-10-31 13:58           ` Stefan Monnier
  1 sibling, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2012-10-31  3:56 UTC (permalink / raw)
  To: 411-done

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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#411: 23.0.60; flet and byte-compilation
  2012-10-31  3:56         ` Glenn Morris
@ 2012-10-31 13:58           ` Stefan Monnier
  2012-10-31 15:01             ` Drew Adams
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2012-10-31 13:58 UTC (permalink / raw)
  To: 411

> 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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#411: 23.0.60; flet and byte-compilation
  2012-10-31 13:58           ` Stefan Monnier
@ 2012-10-31 15:01             ` Drew Adams
  2012-10-31 16:06               ` Stefan Monnier
  0 siblings, 1 reply; 13+ messages in thread
From: Drew Adams @ 2012-10-31 15:01 UTC (permalink / raw)
  To: 'Stefan Monnier', 411

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






^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#411: 23.0.60; flet and byte-compilation
  2012-10-31 15:01             ` Drew Adams
@ 2012-10-31 16:06               ` Stefan Monnier
  2012-10-31 16:13                 ` Drew Adams
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2012-10-31 16:06 UTC (permalink / raw)
  To: Drew Adams; +Cc: 411

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#411: 23.0.60; flet and byte-compilation
  2012-10-31 16:06               ` Stefan Monnier
@ 2012-10-31 16:13                 ` Drew Adams
  0 siblings, 0 replies; 13+ messages in thread
From: Drew Adams @ 2012-10-31 16:13 UTC (permalink / raw)
  To: 'Stefan Monnier'; +Cc: 411

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






^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2012-10-31 16:13 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-25  2:16 bug#411: 23.0.60; flet and byte-compilation Chong Yidong
2008-09-25 17:45 ` Richard M. Stallman
2008-09-26 18:48   ` Glenn Morris
2008-10-20  1:05     ` Glenn Morris
2008-10-23  2:41       ` Glenn Morris
2008-10-23  2:50         ` Processed: " Emacs bug Tracking System
2012-10-31  3:56         ` Glenn Morris
2012-10-31 13:58           ` Stefan Monnier
2012-10-31 15:01             ` Drew Adams
2012-10-31 16:06               ` Stefan Monnier
2012-10-31 16:13                 ` Drew Adams
  -- strict thread matches above, loose matches on Subject: below --
2008-09-15  8:04 Glenn Morris
2008-06-14 15:17 Michael Heerdegen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).