Strange change in bytecmop.el

Strange change in bytecmop.el

[Stefan Monnier]

Regarding the change below:

	* emacs-lisp/bytecomp.el (byte-compile-and-recursion): New function.
	(byte-compile-and): Use byte-compile-and-recursion.
	(byte-compile-or-recursion): New function.
	(byte-compile-or): Use that.
	(byte-compile-if): Guard the else-clause too.
	(byte-compile-maybe-guarded): Handle (not (featurep 'emacs)).

the last part not only is strange because (featurep 'emacs) is never used
(since Emacs does not provide the `emacs' feature) but also because it tries
to handle (featurep 'xemacs) even though that's already handled in
byteopt.el where we do:

   (put 'featurep 'byte-optimizer 'byte-optimize-featurep)
   (defun byte-optimize-featurep (form)
     ;; Emacs-21's byte-code doesn't run under XEmacs anyway, so we can
     ;; safely optimize away this test.
     (if (equal '((quote xemacs)) (cdr-safe form))
         nil
       form))


-- Stefan

Re: Strange change in bytecmop.el

[Juanma Barranquero]

On 7/21/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> the last part not only is strange because (featurep 'emacs) is never used
> (since Emacs does not provide the `emacs' feature)

Yeah, I pointed this out in a message a few days ago. Perhaps it'd be
useful to define the feature 'emacs, but even so it won't be a
reliable way to detect GNU Emacs for years and years...

> but also because it tries
> to handle (featurep 'xemacs) even though that's already handled in
> byteopt.el where we do:

I think the handling in byteopt.el is about generating bytecode (or
not doing it, for XEmacs-specific code) while the one in bytecomp.el
is about not issuing warnings for XEmacs features. For example, it
silences a warning in flymake.el about the use of
`multiple-value-bind'.

-- 
                    /L/e/k/t/u

Re: Strange change in bytecmop.el

[Stefan Monnier]

> I think the handling in byteopt.el is about generating bytecode (or
> not doing it, for XEmacs-specific code) while the one in bytecomp.el
> is about not issuing warnings for XEmacs features. For example, it
> silences a warning in flymake.el about the use of
> `multiple-value-bind'.

The one in byteopt.el was introduced mostly to remove spurious warnings.
The fact that it optimizes the bytecode was just a nicve side-effect.
So I'm wondering in which circumstance the new code is useful/necessary.


        Stefan

Re: Strange change in bytecmop.el

[Richard M. Stallman]

    the last part not only is strange because (featurep 'emacs) is never used
    (since Emacs does not provide the `emacs' feature)

I didn't realize that at the time, but maybe we should add it.

						       but also because it tries
    to handle (featurep 'xemacs) even though that's already handled in
    byteopt.el where we do:

Well, it didn't always do the job.
This code is needed.

Re: Strange change in bytecmop.el

[Stefan Monnier]

>     the last part not only is strange because (featurep 'emacs) is never used
>     (since Emacs does not provide the `emacs' feature)

> I didn't realize that at the time, but maybe we should add it.

Why bother.  People already use (featurep 'xemacs) in order to check whether
they're running on Emacs or XEmacs.  So (featurep 'emacs) would be redundant.

> 						       but also because it tries
>     to handle (featurep 'xemacs) even though that's already handled in
>     byteopt.el where we do:

> Well, it didn't always do the job.
> This code is needed.

Could you give at least some example so we can add relevant comments
explaining the apparent redundancy?


        Stefan

Re: Strange change in bytecmop.el

[Richard M. Stallman]

    Why bother.  People already use (featurep 'xemacs) in order to check whether
    they're running on Emacs or XEmacs.  So (featurep 'emacs) would be redundant.

But that way the code always says (featurep 'xemacs).

Re: Strange change in bytecmop.el

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Why bother.  People already use (featurep 'xemacs) in order to
>     check whether they're running on Emacs or XEmacs.  So (featurep
>     'emacs) would be redundant.
>
> But that way the code always says (featurep 'xemacs).

Naturally.  (featurep 'xemacs) means "here is an exception for the
sake of XEmacs".

We don't have to make exceptions for the sake of Emacs.  We are the
main line.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange change in bytecmop.el

[Richard M. Stallman]

    Naturally.  (featurep 'xemacs) means "here is an exception for the
    sake of XEmacs".

    We don't have to make exceptions for the sake of Emacs.  We are the
    main line.

That's a valid point.  At the same time, it means that our code is
full of mentions of XEmacs.

Re: Strange change in bytecmop.el

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Naturally.  (featurep 'xemacs) means "here is an exception for the
>     sake of XEmacs".
>
>     We don't have to make exceptions for the sake of Emacs.  We are the
>     main line.
>
> That's a valid point.  At the same time, it means that our code is
> full of mentions of XEmacs.

Sure.  As long as we have code intended to run with XEmacs, calling it
anything but code intended to run with XEmacs would be obfuscate.

The only way around that would be to completely remove all such code.
This does not make sense except where code has fallen out of active
maintenance and nobody knows whether it is working, anyway.

XEmacs, after all, does meet the criteria of free software.  Forcing
the maintainers of subsystems that are willing to support XEmacs to
have different distribution paths for versions that also work with
XEmacs would be quite out of proportion in my opinion.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange change in bytecmop.el

[Robert J. Chassell]

David Kastrup <dak@gnu.org> wrote, 

   XEmacs, after all, does meet the criteria of free software.

Actually and unfortunately, we do not know whether it does.

Certainly, the main authors intend that.  But they have not collected
the legal paperwork necessary to prove it to a hostile court.

I agree that

   Forcing the maintainers ... to have different distribution paths
   ...

is wrong.  But the sad truth is that legally (although not morally)
the effort is a waste for themselves and others until the very
bothersome legal requirements are met.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Strange change in bytecmop.el

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> David Kastrup <dak@gnu.org> wrote, 
>
>    XEmacs, after all, does meet the criteria of free software.
>
> Actually and unfortunately, we do not know whether it does.
>
> Certainly, the main authors intend that.  But they have not
> collected the legal paperwork necessary to prove it to a hostile
> court.

It shares this property with a large body of free software.  Not
everybody is as careful as the FSF with regard to copyright
assignments.

Following your way of reasoning, Linux is a non-free operating system
kernel, and we should remove all references to GNU/Linux from Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange change in bytecmop.el

[Richard M. Stallman]

    Sure.  As long as we have code intended to run with XEmacs, calling it
    anything but code intended to run with XEmacs would be obfuscate.

The option we're actually talking about is not obfuscated.

  (if (featurep 'emacs)
      ...
    ...)

Re: Strange change in bytecmop.el

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Sure.  As long as we have code intended to run with XEmacs, calling it
>     anything but code intended to run with XEmacs would be obfuscate.
>
> The option we're actually talking about is not obfuscated.
>
>   (if (featurep 'emacs)
>       ...
>     ...)

Frankly, I can't make head nor tails out of it.  If this is supposed
to differentiate just XEmacs (and it will rule out any older version
of Emacs, too, as collateral), then I find it offensive that the
_default_ code path is for XEmacs, and we have to make an _exception_
for Emacs.  This is so backwards that I consider it repulsive.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange change in bytecmop.el

[Juanma Barranquero]

On 7/25/05, David Kastrup <dak@gnu.org> wrote:

> Sure.  As long as we have code intended to run with XEmacs, calling it
> anything but code intended to run with XEmacs would be obfuscate.
> 
> The only way around that would be to completely remove all such code.
> This does not make sense except where code has fallen out of active
> maintenance and nobody knows whether it is working, anyway.

IMHO, maintaining "(if (boundp 'xemacs)..)" in Emacs code makes sense
when the package affected has a life *outside* Emacs and XEmacs
distributions. For those packages that only live in Emacs and XEmacs
source trees, there are already lots of site-specific changes, and
frankly, for us Emacs maintainers the "(boundp 'xemacs)" bit brings no
benefit: we're not going to sync with XEmacs code because of legal
issues, and it's more code to maintain or at least to consciously
ignore when fixing an issue or otherwise modifying the package.

However, supporting "(boundp 'emacs)" would make sense. I don't think
we're in the business of telling outside elisp developers whether they
should consider Emacs or XEmacs the "main line". If a guy uses XEmacs
and develops a package for it, and he's nice enough to make allowances
for it to work on Emacs, it's a bit absurd to ask him to consider
Emacs the main line and put XEmacs code inside guards. Supporting the
'emacs feature is not a big deal, but it is certainly nicer to
non-Emacs developers (at least long term).

-- 
                    /L/e/k/t/u

Re: Strange change in bytecmop.el

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> However, supporting "(boundp 'emacs)" would make sense.

So, just _when_ would you use it?

> I don't think we're in the business of telling outside elisp
> developers whether they should consider Emacs or XEmacs the "main
> line".

You just said above that making the distinction only makes sense for
packages maintained externally.

> If a guy uses XEmacs and develops a package for it, and he's nice
> enough to make allowances for it to work on Emacs, it's a bit absurd
> to ask him to consider Emacs the main line and put XEmacs code
> inside guards. Supporting the 'emacs feature is not a big deal, but
> it is certainly nicer to non-Emacs developers (at least long term).

I don't see that.  I am afraid of people putting (boundp 'emacs) into
code also for things that Emacs happens to have _now_, even though
XEmacs might gain them in a later synch, or just putting (boundp
'emacs) habitually in without thinking anything about it.

I really think that this is one change that we are better off without.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange change in bytecmop.el

[Juanma Barranquero]

On 7/26/05, David Kastrup <dak@gnu.org> wrote:

> So, just _when_ would you use it?

Me? I wouldn't use it. I don't develop packages with XEmacs as the
primary target. I don't ever intend to.

> You just said above that making the distinction only makes sense for
> packages maintained externally.

And so, what? Obviously, if we added the feature 'emacs it *would not*
be for us to use, just to help outside developers. That's the exact
same reason why some functions we've added are XEmacs-compatible (I
just happen to hate the names `define-obsolete-function-alias' and
`define-obsolete-variable-alias', which I would make shorter in a
blink, but they were added as such because XEmacs already define them,
IIRC).

> I don't see that.  I am afraid of people putting (boundp 'emacs) into
> code also for things that Emacs happens to have _now_, even though
> XEmacs might gain them in a later synch, or just putting (boundp
> 'emacs) habitually in without thinking anything about it.

That's no different of using "(fboundp 'feature-such-and-such)" for
features Emacs already have. And, worrying about people using things
without thinking smells a bit of patronizing, to me. (No insult
intended, I can assure you.)

> I really think that this is one change that we are better off without.

I didn't propose it, so I'm hardly going to enter a fight for it. I
just happen to think is not only not as outrageous as you made it
sound (when you said "This is so backwards that I consider it
repulsive."), but I even think that could be useful.

-- 
                    /L/e/k/t/u

Re: Strange change in bytecmop.el

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> On 7/26/05, David Kastrup <dak@gnu.org> wrote:
>
>> I really think that this is one change that we are better off without.
>
> I didn't propose it, so I'm hardly going to enter a fight for it. I
> just happen to think is not only not as outrageous as you made it
> sound (when you said "This is so backwards that I consider it
> repulsive."), but I even think that could be useful.

Well, we have to agree to disagree, then.  I can see no even slightly
relevant political advantages for this (I am apparently in
disagreement with Richard here, even given rather similar goals), and
it adds no new functionality whatsoever, at the cost of backward
incompatibilities.

If there are no new points to make, I suggest we all just wait with
baited breath what Richard will decide, and then either of us will
have the opportunity to be exasperated.  Though it does not sound like
you in particular would mind much either which way.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange change in bytecmop.el

[Juanma Barranquero]

On 7/26/05, David Kastrup <dak@gnu.org> wrote:

> Though it does not sound like
> you in particular would mind much either which way.

That's it. To me, the exasperation rate of the issue is almost zero. :)

-- 
                    /L/e/k/t/u

Re: Strange change in bytecmop.el

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> I really think that this is one change that we are better off without.

I agree.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Strange change in bytecmop.el

[Richard M. Stallman]

    > Well, it didn't always do the job.
    > This code is needed.

    Could you give at least some example so we can add relevant comments
    explaining the apparent redundancy?

I don't remember what it was, but the bug report was within the past
three weeks.