printing.el again

printing.el again

[Stefan]

In your merge of the two menus, why do you still bother with

          (pr-:visible (if (eq ps-print-emacs-type 'emacs)
			   :visible	; GNU Emacs
			 :included))

since on Emacs, :visible and :included are synonyms anyway.
Also you now do

    (let (...
          pr-:help)
      (if (eq ps-print-emacs-type 'emacs)
	  (defalias 'pr-:help #'(lambda (text) (list :help text))) ; GNU Emacs
	(defalias 'pr-:help 'ignore))				   ; XEmacs

which does not do what you think.  The `let' binding of the `pr-:help'
variable has *no effect* on the `pr-:help' function (the two name spaces are
separate).  I.e. the pr-:help function ends up defined globally anyway so
you had better define it at toplevel so it's less misleading (or otherwise,
you'd want to use CL's `flet' if you want to locally define a function).


        Stefan

Re: printing.el again

[Vinicius Jose Latorre]

Hi Stefan,


 > In your merge of the two menus, why do you still bother with
 >
 >           (pr-:visible (if (eq ps-print-emacs-type 'emacs)
 >                :visible    ; GNU Emacs
 >              :included))
 >
 > since on Emacs, :visible and :included are synonyms anyway.
 > Also you now do

Ok, I just forgot about this. I'll modify printing.


 >     (let (...
 >           pr-:help)
 >       (if (eq ps-print-emacs-type 'emacs)
 >       (defalias 'pr-:help #'(lambda (text) (list :help text))) ; GNU 
Emacs
 >     (defalias 'pr-:help 'ignore))                   ; XEmacs
 >
 > which does not do what you think.  The `let' binding of the `pr-:help'
 > variable has *no effect* on the `pr-:help' function (the two name 
spaces are
 > separate).  I.e. the pr-:help function ends up defined globally anyway so
 > you had better define it at toplevel so it's less misleading (or 
otherwise,
 > you'd want to use CL's `flet' if you want to locally define a function).

Hummm, indeed, but this:

 (let (...
       (pr-:help (if (eq ps-print-emacs-type 'emacs)
                  #'(lambda (text) (list :help text))  ; GNU Emacs
                'ignore)))                  ; XEmacs
  ......
  ,@(funcall pr-:help ...)

Will do the work and pr-:help will be local.


Thanks,


Vinicius

Re: printing.el again

[Stefan Monnier]

> Hummm, indeed, but this:

>  (let (...
>        (pr-:help (if (eq ps-print-emacs-type 'emacs)
>                   #'(lambda (text) (list :help text))  ; GNU Emacs
>                 'ignore)))                  ; XEmacs
>   ......
>   ,@(funcall pr-:help ...)

> Will do the work and pr-:help will be local.

Yes, that's another solution.  I find CL's `flet' much more elegant, tho.
BTW, if you use (featurep 'xemacs) for the test, Emacs-21 will optimize the
test away (since the resulting elc file can't be run on XEmacs anyway).
Here it doesn't really matter, but it is sometimes very handy since it
ends up getting rid of spurious warnings about XEmacs-specific code.


        Stefan

Re: printing.el again

[Vinicius Jose Latorre]

 > > Hummm, indeed, but this:
 >
 > >  (let (...
 > >        (pr-:help (if (eq ps-print-emacs-type 'emacs)
 > >                   #'(lambda (text) (list :help text))  ; GNU Emacs
 > >                 'ignore)))                  ; XEmacs
 > >   ......
 > >   ,@(funcall pr-:help ...)
 >
 > > Will do the work and pr-:help will be local.
 >
 > Yes, that's another solution.  I find CL's `flet' much more elegant, tho.

Ok, but a very long time ago there was a recommendation to do not use cl
package when writing code in Emacs Lisp.

Is that recommendation no more valid?


 > BTW, if you use (featurep 'xemacs) for the test, Emacs-21 will 
optimize the
 > test away (since the resulting elc file can't be run on XEmacs anyway).
 > Here it doesn't really matter, but it is sometimes very handy since it
 > ends up getting rid of spurious warnings about XEmacs-specific code.

Well, so:

A) (cond ((eq ps-print-emacs-type 'xemacs) ...)
         (t ...))

B) (cond ((featurep 'xemacs) ...)
         (t ...))

Are you saying that A and B above are treated differently by the
byte-compiler??


Vinicius

Re: printing.el again

[Stefan Monnier]

> Ok, but a very long time ago there was a recommendation to do not use cl
> package when writing code in Emacs Lisp.
> Is that recommendation no more valid?

CL functions should indeed not be used by packages distributed with Emacs.
OTOH, CL macros (such as `push', `flet', ...) can be used just fine (just
don't forget to put a (eval-when-compile (require 'cl)) at the top of your
file).

>> BTW, if you use (featurep 'xemacs) for the test, Emacs-21 will optimize
>> the test away (since the resulting elc file can't be run on XEmacs
>> anyway).  Here it doesn't really matter, but it is sometimes very handy
>> since it ends up getting rid of spurious warnings about
>> XEmacs-specific code.

> Well, so:

> A) (cond ((eq ps-print-emacs-type 'xemacs) ...)
>          (t ...))

> B) (cond ((featurep 'xemacs) ...)
>          (t ...))

> Are you saying that A and B above are treated differently by the
> byte-compiler??

Yes.

The byte-compiler will not optimize away the `eq' test because it considers
that the user might change ps-print-emacs-type at any time.  OTOH the
byte-compiler knows that since the code it generates doesn't work under
XEmacs, (featurep 'xemacs) will always return nil.


        Stefan

Re: printing.el again

[Vinicius Jose Latorre]

 > > Ok, but a very long time ago there was a recommendation to do not 
use cl
 > > package when writing code in Emacs Lisp.
 > > Is that recommendation no more valid?
 >
 > CL functions should indeed not be used by packages distributed with 
Emacs.
 > OTOH, CL macros (such as `push', `flet', ...) can be used just fine (just
 > don't forget to put a (eval-when-compile (require 'cl)) at the top of 
your
 > file).

Ok.


 > > > BTW, if you use (featurep 'xemacs) for the test, Emacs-21 will 
optimize
 > > > the test away (since the resulting elc file can't be run on XEmacs
 > > > anyway).  Here it doesn't really matter, but it is sometimes very 
handy
 > > > since it ends up getting rid of spurious warnings about
 > > > XEmacs-specific code.
 > >
 > > Well, so:
 > >
 > > A) (cond ((eq ps-print-emacs-type 'xemacs) ...)
 > >          (t ...))
 > >
 > > B) (cond ((featurep 'xemacs) ...)
 > >          (t ...))
 > >
 > > Are you saying that A and B above are treated differently by the
 > > byte-compiler??
 >
 > Yes.
 >
 > The byte-compiler will not optimize away the `eq' test because it 
considers
 > that the user might change ps-print-emacs-type at any time.  OTOH the
 > byte-compiler knows that since the code it generates doesn't work under
 > XEmacs, (featurep 'xemacs) will always return nil.

So, I'll modify to use (featurep 'xemacs).

Does the byte-compiler do constant folding optimization or it is an ad hoc
optimization?

Maybe this should be documented in Emacs Lisp Reference or in other suitable
info, probably Byte Compiler Users Guide.  Also other byte-compiler
optimizations should be documented.


Vinicius

Re: printing.el again

[Stefan]

> Does the byte-compiler do constant folding optimization or it is an ad hoc
> optimization?

It's pretty ad-hoc.  But it does do some amount of constant folding.

> Maybe this should be documented in Emacs Lisp Reference or in other
> suitable info, probably Byte Compiler Users Guide.  Also other
> byte-compiler optimizations should be documented.

Actually, I don't think optimizations should be particularly mentioned.
The interesting part of optimizing (featurep 'xemacs) is that it eliminates
spurious warnings.  There are other ways to get the same effect, such as
what is done with (if (fboundp 'foo) ...) where the test is not optimized
away, but where warnings are selectively prevented.

I think a chapter on "eliminating warnings" is in order to document the use of
(featurep 'xemacs), (fboundp 'foo), (defvar foo), (with-no-warning ...), ...


        Stefan

Re: printing.el again

[Luc Teirlinck]

Stefan Monnier wrote:

   I think a chapter on "eliminating warnings" is in order to document
   the use of (featurep 'xemacs), (fboundp 'foo), (defvar foo),
   (with-no-warning ...), ...

There is `(elisp)Compiler Errors'.  It does not document
(featurep 'xemacs), however.

Sincerely,

Luc.

Re: printing.el again

[Ralf Angeli]

* Stefan (2004-11-16) writes:

> Actually, I don't think optimizations should be particularly mentioned.
> The interesting part of optimizing (featurep 'xemacs) is that it eliminates
> spurious warnings.  There are other ways to get the same effect, such as
> what is done with (if (fboundp 'foo) ...) where the test is not optimized
> away, but where warnings are selectively prevented.

Is it planned to recognize (and (fboundp 'foo) ...) and (and (boundp
'foo) ...) as well?  In AUCTeX we have a lot of them and consequently
a lot of warnings from the byte compiler.

-- 
Ralf

Re: printing.el again

[Stefan Monnier]

>> Actually, I don't think optimizations should be particularly mentioned.
>> The interesting part of optimizing (featurep 'xemacs) is that it eliminates
>> spurious warnings.  There are other ways to get the same effect, such as
>> what is done with (if (fboundp 'foo) ...) where the test is not optimized
>> away, but where warnings are selectively prevented.

> Is it planned to recognize (and (fboundp 'foo) ...) and (and (boundp
> 'foo) ...) as well?

As soon as someone writes the patch for it.


        Stefan

Re: printing.el again

[Vinicius Jose Latorre]

Stefan wrote:

>> Maybe this should be documented in Emacs Lisp Reference or in other
>> suitable info, probably Byte Compiler Users Guide. Also other
>> byte-compiler optimizations should be documented.
>
>
> Actually, I don't think optimizations should be particularly mentioned.
> The interesting part of optimizing (featurep 'xemacs) is that it 
> eliminates
> spurious warnings. There are other ways to get the same effect, such as
> what is done with (if (fboundp 'foo) ...) where the test is not optimized
> away, but where warnings are selectively prevented.
>
> I think a chapter on "eliminating warnings" is in order to document 
> the use of
> (featurep 'xemacs), (fboundp 'foo), (defvar foo), (with-no-warning 
> ...), ...


Well, I think it's important to know the optimizations we can use or not 
and when.

Does the byte-compiler try to optimize featurep in general or only the 
pattern (featurep 'xemacs) is optimized?

That is, if I have a code which test (featurep 'some-package) and 
some-package is not loaded, does the byte-compiler eliminate the code 
associated with this test?


Vinicius

Re: printing.el again

[Stefan Monnier]

> Well, I think it's important to know the optimizations we can use or not
> and when.

I don't understand.  *You* can't use an optimization: the byte-compiler can.

> That is, if I have a code which test (featurep 'some-package) and
> some-package is not loaded, does the byte-compiler eliminate the code
> associated with this test?

Think of it this way: any optimization should be "semantics preserving" and
should thus only affect the CPU and memory usage but not the beavior.  So if
you can think of a case where an optimization induces a different behavior,
there are 3 possibilities:
1 - this case is really outlandish and can be itself considered a bug
    (e.g. someone does (provide 'xemacs)).
2 - the case is a real problem and thus the byte-compiler does not use this
    optimization.
3 - the case is a real problem but the compiler does use the optimization,
    in which case you have uncovered a byte-compiler bug and you should
    report it.


        Stefan

Re: printing.el again

[Vinicius Jose Latorre]

 > > Well, I think it's important to know the optimizations we can use 
or not
 > > and when.
 >
 > I don't understand.  *You* can't use an optimization: the 
byte-compiler can.

Rephrasing:

Well, I think it's important to know the optimizations we can SET or not and
when.

Like when you use gcc:

   gcc -O3

You set above optimization level 3.

Did you understand?


 > > That is, if I have a code which test (featurep 'some-package) and
 > > some-package is not loaded, does the byte-compiler eliminate the code
 > > associated with this test?
 >
 > Think of it this way: any optimization should be "semantics 
preserving" and
 > should thus only affect the CPU and memory usage but not the 
beavior.  So if
 > you can think of a case where an optimization induces a different 
behavior,
 > there are 3 possibilities:
 > 1 - this case is really outlandish and can be itself considered a bug
 >     (e.g. someone does (provide 'xemacs)).
 > 2 - the case is a real problem and thus the byte-compiler does not 
use this
 >     optimization.
 > 3 - the case is a real problem but the compiler does use the 
optimization,
 >     in which case you have uncovered a byte-compiler bug and you should
 >     report it.

Consider the following code:

(defun foo (arg)
   (if (featurep 'someone-package)
      (behavior-A)
    (behavior-B)))

Does the byte-compiler "optimize" the code above?

(featurep 'xemacs) is ok, because you are saying in which system all 
packages
will run.  But if you write a code to have a behavior depending on the 
packages
that are loaded in a given moment, maybe it's not ok.

So, if someone-package is not loaded, the foo is byte-compiled and the
"featurep optimization" is done, the result is:

(defun foo (arg)
  (behavior-B))

If someone-package is loaded later, then the code above will not execute as
behavior-A.

So, "featurep optimization" in general is not good.  But (featurep 'xemacs)
optimization is good.


Vinicius

Re: printing.el again

[Stefan Monnier]

> So, "featurep optimization" in general is not good.  But (featurep 'xemacs)
> optimization is good.

And based on what I told you, you'd then infer that either the byte-compiler
only optimizes (featurep 'xemacs) and not the other cases, or it has a bug.


        Stefan

Re: printing.el again

[Richard Stallman]

    Well, I think it's important to know the optimizations we can SET or not and
    when.

I don't think this is a desirable direction for Emacs development,
The compiler optimizations should "just work", and users don't
need to know about them, so it would be wasteful to describe them
in the manual.

We are aiming to make a release, so please everyone let's not get
distracted by questions like this one.  Please focus your efforts
on correcting bugs.

Re: printing.el again

[Richard Stallman]

     > Yes, that's another solution.  I find CL's `flet' much more elegant, tho.

It is ok to use the CL macros in general, but the use of flet on a
function that is not internal to your package is really un-cool.

Using flet on a function name internal to your package is ok, but I
think that if you have a value that varies, it is better to use a
variable name for it.