all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* printing.el again
@ 2004-11-14  5:59 Stefan
  2004-11-14 15:29 ` Vinicius Jose Latorre
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan @ 2004-11-14  5:59 UTC (permalink / raw)



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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-14  5:59 printing.el again Stefan
@ 2004-11-14 15:29 ` Vinicius Jose Latorre
  2004-11-14 19:20   ` Stefan Monnier
  0 siblings, 1 reply; 16+ messages in thread
From: Vinicius Jose Latorre @ 2004-11-14 15:29 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-14 15:29 ` Vinicius Jose Latorre
@ 2004-11-14 19:20   ` Stefan Monnier
  2004-11-15 20:03     ` Vinicius Jose Latorre
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2004-11-14 19:20 UTC (permalink / raw)
  Cc: emacs-devel

> 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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-14 19:20   ` Stefan Monnier
@ 2004-11-15 20:03     ` Vinicius Jose Latorre
  2004-11-15 20:47       ` Stefan Monnier
  2004-11-17  5:03       ` Richard Stallman
  0 siblings, 2 replies; 16+ messages in thread
From: Vinicius Jose Latorre @ 2004-11-15 20:03 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-15 20:03     ` Vinicius Jose Latorre
@ 2004-11-15 20:47       ` Stefan Monnier
  2004-11-16  0:55         ` Vinicius Jose Latorre
  2004-11-17  5:03       ` Richard Stallman
  1 sibling, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2004-11-15 20:47 UTC (permalink / raw)
  Cc: emacs-devel

> 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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-15 20:47       ` Stefan Monnier
@ 2004-11-16  0:55         ` Vinicius Jose Latorre
  2004-11-16  1:29           ` Stefan
  0 siblings, 1 reply; 16+ messages in thread
From: Vinicius Jose Latorre @ 2004-11-16  0:55 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-16  0:55         ` Vinicius Jose Latorre
@ 2004-11-16  1:29           ` Stefan
  2004-11-16  1:36             ` Luc Teirlinck
                               ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Stefan @ 2004-11-16  1:29 UTC (permalink / raw)
  Cc: emacs-devel

> 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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-16  1:29           ` Stefan
@ 2004-11-16  1:36             ` Luc Teirlinck
  2004-11-16 14:47             ` Ralf Angeli
  2004-11-18  1:53             ` Vinicius Jose Latorre
  2 siblings, 0 replies; 16+ messages in thread
From: Luc Teirlinck @ 2004-11-16  1:36 UTC (permalink / raw)
  Cc: viniciusjl, emacs-devel

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-16  1:29           ` Stefan
  2004-11-16  1:36             ` Luc Teirlinck
@ 2004-11-16 14:47             ` Ralf Angeli
  2004-11-16 16:51               ` Stefan Monnier
  2004-11-18  1:53             ` Vinicius Jose Latorre
  2 siblings, 1 reply; 16+ messages in thread
From: Ralf Angeli @ 2004-11-16 14:47 UTC (permalink / raw)


* 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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-16 14:47             ` Ralf Angeli
@ 2004-11-16 16:51               ` Stefan Monnier
  0 siblings, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2004-11-16 16:51 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-15 20:03     ` Vinicius Jose Latorre
  2004-11-15 20:47       ` Stefan Monnier
@ 2004-11-17  5:03       ` Richard Stallman
  1 sibling, 0 replies; 16+ messages in thread
From: Richard Stallman @ 2004-11-17  5:03 UTC (permalink / raw)
  Cc: monnier, emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-16  1:29           ` Stefan
  2004-11-16  1:36             ` Luc Teirlinck
  2004-11-16 14:47             ` Ralf Angeli
@ 2004-11-18  1:53             ` Vinicius Jose Latorre
  2004-11-18 16:30               ` Stefan Monnier
  2 siblings, 1 reply; 16+ messages in thread
From: Vinicius Jose Latorre @ 2004-11-18  1:53 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-18  1:53             ` Vinicius Jose Latorre
@ 2004-11-18 16:30               ` Stefan Monnier
  2004-11-18 22:44                 ` Vinicius Jose Latorre
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2004-11-18 16:30 UTC (permalink / raw)
  Cc: emacs-devel

> 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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-18 16:30               ` Stefan Monnier
@ 2004-11-18 22:44                 ` Vinicius Jose Latorre
  2004-11-18 23:31                   ` Stefan Monnier
  2004-11-19 20:04                   ` Richard Stallman
  0 siblings, 2 replies; 16+ messages in thread
From: Vinicius Jose Latorre @ 2004-11-18 22:44 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-18 22:44                 ` Vinicius Jose Latorre
@ 2004-11-18 23:31                   ` Stefan Monnier
  2004-11-19 20:04                   ` Richard Stallman
  1 sibling, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2004-11-18 23:31 UTC (permalink / raw)
  Cc: emacs-devel

> 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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: printing.el again
  2004-11-18 22:44                 ` Vinicius Jose Latorre
  2004-11-18 23:31                   ` Stefan Monnier
@ 2004-11-19 20:04                   ` Richard Stallman
  1 sibling, 0 replies; 16+ messages in thread
From: Richard Stallman @ 2004-11-19 20:04 UTC (permalink / raw)
  Cc: monnier, emacs-devel

    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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2004-11-19 20:04 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-14  5:59 printing.el again Stefan
2004-11-14 15:29 ` Vinicius Jose Latorre
2004-11-14 19:20   ` Stefan Monnier
2004-11-15 20:03     ` Vinicius Jose Latorre
2004-11-15 20:47       ` Stefan Monnier
2004-11-16  0:55         ` Vinicius Jose Latorre
2004-11-16  1:29           ` Stefan
2004-11-16  1:36             ` Luc Teirlinck
2004-11-16 14:47             ` Ralf Angeli
2004-11-16 16:51               ` Stefan Monnier
2004-11-18  1:53             ` Vinicius Jose Latorre
2004-11-18 16:30               ` Stefan Monnier
2004-11-18 22:44                 ` Vinicius Jose Latorre
2004-11-18 23:31                   ` Stefan Monnier
2004-11-19 20:04                   ` Richard Stallman
2004-11-17  5:03       ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.