Re: printing.el again

[Vinicius Jose Latorre <viniciusjl@ig.com.br>]

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