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