push and pop

push and pop

[JD Smith]

The macros "push" and "pop" in `subr' don't do the same thing as the push
and pop in `cl'.  This means that if you use:

 (eval-when-compile (require 'cl))

in your code, the behavior will change depending on whether the compiled
version is loaded (cl version), or you are interactively debugging (subr
version).  An example of a semantic which will fail with the subr version
but not the cl version:

 (setq ov (pop (cdr ov-list)))

which requires a list argument to pop, instead of the cdr of a list.

Any suggestions on how to work around this (other than the obvious "don't
do that")?

Thanks,

JD

Re: push and pop

[David Kastrup]

JD Smith <jdsmith@as.arizona.edu> writes:

> The macros "push" and "pop" in `subr' don't do the same thing as the push
> and pop in `cl'.  This means that if you use:
>
>  (eval-when-compile (require 'cl))
>
> in your code, the behavior will change depending on whether the compiled
> version is loaded (cl version), or you are interactively debugging (subr
> version).  An example of a semantic which will fail with the subr version
> but not the cl version:
>
>  (setq ov (pop (cdr ov-list)))
>
> which requires a list argument to pop, instead of the cdr of a list.
>
> Any suggestions on how to work around this (other than the obvious
> "don't do that")?

Well, don't do that.  If you require the cl-behavior, then of course
you'll also require it for debugging.  It's the same with any macro
providing package, not just with cl.

Anyway, this is not an issue if you do
(load "filename")
after some change: in that case cl.el will get loaded.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: push and pop

[Stefan Monnier]

> The macros "push" and "pop" in `subr' don't do the same thing as the push
> and pop in `cl'.  This means that if you use:

>  (eval-when-compile (require 'cl))

> in your code, the behavior will change depending on whether the compiled
> version is loaded (cl version), or you are interactively debugging (subr
> version).  An example of a semantic which will fail with the subr version
> but not the cl version:

>  (setq ov (pop (cdr ov-list)))

> which requires a list argument to pop, instead of the cdr of a list.

I don't see the problem.  When debugging code in a file that does (require
FOO), you need to (require FOO) before doing C-x C-e or M-C-x.
Nothing new here.

The only difference is that in macs-20 (when subr.el didn't define its iown
version of `pop') you'd get an error "void function `pop'" whereas now you
get another error.

> Any suggestions on how to work around this (other than the obvious "don't
> do that")?

Don't do that,


        Stefan

Re: push and pop

[JD Smith]

On Fri, 2005-01-07 at 15:23 -0500, Stefan Monnier wrote:
> > The macros "push" and "pop" in `subr' don't do the same thing as the push
> > and pop in `cl'.  This means that if you use:
> 
> >  (eval-when-compile (require 'cl))
> 
> > in your code, the behavior will change depending on whether the compiled
> > version is loaded (cl version), or you are interactively debugging (subr
> > version).  An example of a semantic which will fail with the subr version
> > but not the cl version:
> 
> >  (setq ov (pop (cdr ov-list)))
> 
> > which requires a list argument to pop, instead of the cdr of a list.
> 
> I don't see the problem.  When debugging code in a file that does (require
> FOO), you need to (require FOO) before doing C-x C-e or M-C-x.
> Nothing new here.
> 
> The only difference is that in macs-20 (when subr.el didn't define its iown
> version of `pop') you'd get an error "void function `pop'" whereas now you
> get another error.

I think the confusion for me and lots of others: many installs (like
Fedora/Red Hat) include site-start stuff that does (or did) a (require
'cl) somewhere.  So it comes as unexpected when that stuff isn't
available.  So, in every emacs-20 I'd ever used, you'd get no such
error, since cl had already been loaded by default.  

When I'm debugging the code that needs FOO, the code has already been
run in that Emacs session, so it's natural to expect all of its
requirements to have been loaded.  In hindsight, I guess it makes sense
that a compile-time macro would not be loaded (since it's compiled in by
eval-when-compile) unless you explicitly reload it.  

Thanks for the pointers.

JD

Re: push and pop

[Miles Bader]

> I think the confusion for me and lots of others: many installs (like
> Fedora/Red Hat) include site-start stuff that does (or did) a (require
> 'cl) somewhere.  So it comes as unexpected when that stuff isn't
> available.  So, in every emacs-20 I'd ever used, you'd get no such
> error, since cl had already been loaded by default.

I think you should be complaining to Red Hat...

-Miles

Re: push and pop

[Richard Stallman]

    I think the confusion for me and lots of others: many installs (like
    Fedora/Red Hat) include site-start stuff that does (or did) a (require
    'cl) somewhere.

Changing Emacs that way is not a good idea.  If people come across
these in the future, would you please complain to the maintainers
of those distros?

Re: push and pop

[JD Smith]

On Sat, 2005-01-08 at 08:34, Richard Stallman wrote:
>     I think the confusion for me and lots of others: many installs (like
>     Fedora/Red Hat) include site-start stuff that does (or did) a (require
>     'cl) somewhere.
> 
> Changing Emacs that way is not a good idea.  If people come across
> these in the future, would you please complain to the maintainers
> of those distros?

I should point out that this has since been fixed in recent Fedora
releases, which is why I encountered the new behavior in the first
place.  Is there a technical reason the subr push and pop can't behave
like the cl versions?  I suspect they're the most commonly used of the
cl macros, and it's confusing to have similarly named macros with
different behavior.

JD

Re: push and pop

[Francis Litterio]

JD Smith wrote:

> Is there a technical reason the subr push and pop can't behave
> like the cl versions?

The biggest reason is that it would violate an interface contract.  You
aren't seriously proposing changing the semantics of the push and pop
subrs?
--
Francis Litterio
franl <at> world . std . com

Re: push and pop

[Luc Teirlinck]

JD Smith wrote:

   Is there a technical reason the subr push and pop can't behave
   like the cl versions?

I would guess because Elisp does not have `setf' and hence not this
CL-type very general notion of setting a "place".

   I suspect they're the most commonly used of the cl macros, and it's
   confusing to have similarly named macros with different behavior.

At least they only differ in cases where the Elisp version throws an error.

Sincerely,

Luc.

Re: push and pop

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> JD Smith wrote:
>
>    Is there a technical reason the subr push and pop can't behave
>    like the cl versions?
>
> I would guess because Elisp does not have `setf' and hence not this
> CL-type very general notion of setting a "place".

My guess as well.  So the question would be whether it would desirable
if Elisp were to get setf as a standard macro.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: push and pop

[Richard Stallman]

    My guess as well.  So the question would be whether it would desirable
    if Elisp were to get setf as a standard macro.

I don't want to make such a big extension to Emacs Lisp in that way.