byte-compiler warnings

byte-compiler warnings

[Joost Kremers]

hi all,

having upgraded to GNU Emacs 23.2.1, some of my elisp code that used to compile
without any messages now produces some warnings. the first is:

Function `copy-list' from cl package called at runtime

this one appears a couple of times, also for `gensym' and `evenp'.

i do require the cl package at compile time, but since copy-list, gensym and
evenp are functions, that of course doesn't help.

 if i require the package at runtime, the byte compiler complains about it, too:
"cl package required at runtime"...

so isn't one supposed to use these functions at all, except in private code?

the second warning i get is:

`save-excursion' defeated by `set-buffer'

this applies to code chunks like the following:

(save-excursion
  (set-buffer <some-buffe>
  ...

in each case, i can actually take out the save-excursion, i think, because the
save-excursion scopes until the end of the function it's in and that's where the
effect of set-buffer ends anyway. but it does make me curious, why this warning
never appeared in previous emacs versions. and looking at the elisp info files a
bit, i find that besides set-buffer there are also save-current-buffer and
with-current-buffer, which seem to do pretty much the same thing. anyone know
which function is preferred in which situation?

TIA


-- 
Joost Kremers                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Byte-compiler warnings

[Marcin Borkowski]

Hi all,

I remember someone somewhere writing that Emacs byte-compiler is useful
even if you don't want the compiled code, since it issues various
warnings about bad Elisp constructs.  I didn't find much about it in the
manual, which referred to the docstring of the variable
`byte-compile-warnings'.  That docstring gave a list of symbols denoting
various categories of warnings; the most interesting were probably
`mapcar' and `suspicious'.  Grepping the `bytecomp.el' source (GNU Emacs
25.0.50.1) seems to imply that currently the only case where 'suspicious
is used is a combination of `save-excursion' and `set-buffer'.  Am
I right?

Are there other tools that assist in writing good Elisp code?  I know
about checkdoc, is there anything else?

TIA,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Byte-compiler warnings

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> I remember someone somewhere writing that Emacs
> byte-compiler is useful even if you don't want the
> compiled code, since it issues various warnings
> about bad Elisp constructs.

Whoever said that must have been pretty cool :))

But yes. There are many such cases. The help should
have the exact same message, is the way I would do it.
But its not a big issue if it is there in some
other phrasing.

E.g.,

    (defun compile-me ()
      (beginning-of-buffer) )

The help says:

    Don't use this command in Lisp programs!
    (goto-char (point-min)) is faster.

The byte-compiler says:

    ~/.emacs:6:8:Warning: `beginning-of-buffer' is for
    interactive use only; use `(goto-char
    (point-min))' instead.

One question is: if (goto-char (point-min)) is
equivalent, why cannot the byte-compiler just use that
instead for the compiled version? (Granted, there
might be more complicated examples that
`beginning-of-buffer' vs. (goto-char (point-min))...)

> Are there other tools that assist in writing good
> Elisp code? I know about checkdoc, is there
> anything else?

When you have your program you can set up automatic
testing to test all possible arg values, and such
things. It won't have anything to do with good Lisp
but it will find the bugs. Which is much more
important. But I agree a set of such tools would be
cool insofar as what is needed cannot be incorporated
into either of the components already mentioned...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Byte-compiler warnings

[Nicolas Richard]

Emanuel Berg <embe8573@student.uu.se> writes:
> One question is: if (goto-char (point-min)) is
> equivalent, why cannot the byte-compiler just use that
> instead for the compiled version?

It's not equivalent.

e.g. if you want to set point at beginning of line, you can use
beginning-of-line (or forward-line, depending on the circumstances)

Now what the warning says is : if you're interested in move to
beginning-of-buffer, don't use beginning-of-buffer, use the other
approach instead.

-- 
Nico

Re: Byte-compiler warnings

[Stefan Monnier]

> One question is: if (goto-char (point-min)) is
> equivalent, why cannot the byte-compiler just use that
> instead for the compiled version?

In general such "use <foo> instead" messages are used instead of doing
the rewrite silently for two reasons:
1- the two aren't actually equivalent.  The provide the same feature but
   in different ways or with different corner case behavior, so the compiler
   can't safely replace one for the other.  E.g. beginning-of-buffer
   sets the mark; which is the reason why it's usually not what you want
   from Elisp, but the compiler can't know if that's actually what you want.
2- the two are equivalent, but one is deprecated so we want people to
   fix the source code.  This might be also because the compiler can
   detect and optimize some cases but not all, so it's important to tell
   the programmer that these forms are deprecated so she can hopefully
   stop using them also in those places that the byte-compiler can't
   detect (e.g. '(lambda ...) vs #'(lambda ...) which then compiler can
   detect when passed to `apply' or `mapcar' but not in general since in
   general '(lambda ...) might just be a list rather than a function).


        Stefan

Re: Byte-compiler warnings

[Pascal J. Bourguignon]

Marcin Borkowski <mbork@mbork.pl> writes:

> Are there other tools that assist in writing good Elisp code?  I know
> about checkdoc, is there anything else?

Once upon a time, there was a lot of such tools to help writing lisp
code, including code pattern matcher, expert systems, AI user models,
etc.

Unfortunately they were developped before a common lisp was designed
(namely, ANSI Common Lisp), and before it was customary to publish
source code in git repositories (even cvs didn't exist yet).  Therefore
you only find echoes of them in scientific papers, and rarely find
sources.  But even if you found sources, they often couldn't be used
both for licensing reasons and for technical reasons.

So no, we don't abound in such tools, be it for Common Lisp or for emacs
lisp.  There's a CL lint around, perhaps it could be adapted for emacs
lisp.


In any case, the point of lisp is that it is easy to write such tools,
because the syntax of lisp code is a subset of the syntax of lisp data,
and therefore you can read lisp code as lisp data.  On the other hand,
people edit text files as sources, and may want to preserve things that
are not in the sexp data of their sources, like comments, newlines,
spacing, and exact textual form of lisp objects that have several
representations.  This complicates the processing of lisp code, since
you have to actually process the text file.  And you may want to produce
advices about the formatting and commenting of those text files too
anyways. 

But this is not something that emacs cannot do easily.

So go ahead, read some old papers for inspiration, and write some nice
emacs lisp programmer assistant tool!





http://www.ai.univ-paris8.fr/~hw/mespubs.html
http://www.softwarepreservation.org/projects/LISP/interlisp

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: Byte-compiler warnings

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

>> Are there other tools that assist in writing good
>> Elisp code? I know about checkdoc, is there
>> anything else?
>
> Once upon a time, there was a lot of such tools to
> help writing lisp code, including code pattern
> matcher, expert systems, AI user models, etc.

Expert system = a state machine where states are
questions to the user and edges are the the answers
supplied. E.g.: Where does it hurt? "The leg" What
part of the leg? "The knee" and so on until it reaches
an endpoint where the expert sub presents the problem
in no uncertain terms, as well as the corresponding
solution(s).

This can be combined with probability theory in order
to make a computer do very well in games like
"20 questions".

Expert systems was a pet subject during the AI bubble
and even textbooks on AI often proudly come with
"expert system" in their titles.

The inherent drawback is most real-world problems are
either complicated (like repairing a bike) however not
complicated enough for an expert system to be helpful
continuously, *or* the problems are very complicated
indeed (how to make a girl fall in love with you) BUT
those problems are impossible to formalize so they
can't be computed anyway!

So, yet another AI bummer.

> So no, we don't abound in such tools, be it for
> Common Lisp or for emacs lisp. There's a CL lint
> around, perhaps it could be adapted for emacs lisp.

Not in the Debian repos it isn't what I can hit.
But: 'aptitude search lint | grep -i perl' (five
hits), three hits on html, and so on.

By the way: in the Wiki article "List of tools for
static code analysis" [1] there isn't a single mention
of Lisp!

> In any case, the point of lisp is that it is easy to
> write such tools

In at least one efficient and basic case there
shouldn't even be a need for a language-specific tool,
and that is the search for code duplication - to
identify blocks of code that reoccurs and thus should
be factored out. But I'm not able to find that kind of
tool either! I've heard of CPD (copy paste duplicate)
but can't find it anywhere except for a PHP version in
the repos. Someone do "KYD" (kill yank duplicate) for
Elisp... :) But again I don't see why this is
language-specific other than not considering comments
or indentation!

[1] https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Byte-compiler warnings

[Emanuel Berg]

In the ELPAs and MELPAs there are a couple of hits on
refactor, lint, and so on. Perhaps anyone on this list
has experience from them and can tell what stuff
they do.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Byte-compiler warnings

[Stefan Monnier]

>> Are there other tools that assist in writing good Elisp code?  I know
>> about checkdoc, is there anything else?
> Once upon a time, there was a lot of such tools to help writing lisp
> code, including code pattern matcher, expert systems, AI user models,
> etc.

The tendency over the year has been first to move it all into the
compiler (since the kind of analysis needed to give those warnings is
often useful for a compiler to generate better code as well), and then
to add specialized tools again (that focus on particular coding errors).
IIUC the reason to develop the newer tools separately from the compilers
is because they tend to use different analyses (e.g. more superficial
(paying attention to identifier names), or much more costly, or that
require extra information/setup from the coders, ...).

In any case, within the Elisp realm, we're still at the stage where the
compiler is the most common place to add warnings.  There are a few other
tools (elint and checkdoc), of course.


        Stefan

Re: Byte-compiler warnings

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The tendency over the year has been first to move it
> all into the compiler (since the kind of analysis
> needed to give those warnings is often useful for
> a compiler to generate better code as well), and
> then to add specialized tools again (that focus on
> particular coding errors). IIUC the reason to
> develop the newer tools separately from the
> compilers is because they tend to use different
> analyses (e.g. more superficial (paying attention to
> identifier names), or much more costly, or that
> require extra information/setup from the coders,
> ...).

If it were up to me, superficial or super-costly, it
would still be placed along with the compiler and
invoked with options rather than having that as
separate tools.

> In any case, within the Elisp realm, we're still at
> the stage where the compiler is the most common
> place to add warnings. There are a few other tools
> (elint and checkdoc), of course.

The compiler warnings are great and perhaps more can
be added still? For example, remember the discussion
`if' and (if (not ...)) vs `when' and `unless'? No?
Anyway at that time I thought `if' was better because
then you can add an else clause later (if necessary)
without having to change the function, and you can
start writing the block without thinking how it will
end. I understand that thinking but for whatever
reason somewhere along the way I just started using
when/unless instead and now I think those are much
better whenever there isn't an else path (with
when/unless, `if' also signals there is one).
Perhaps the compiler can warn about that as well? But,
if it gets that aggressive and subjective in, eh,
"style", then people will get crazy if they can't shut
it up if their style conflicts. So I think warnings
should be added in the thousands, and then mutable one
by one...

I'll try elint tomorrow. checkdoc is good, no doubt,
as is the help. Not all functions in official Emacs
(in Gnus, for example) do as checkdoc says and mention
the args in the correct order and all that. It makes
sense and is easy, so why not just do it?

-- 
underground experts united
http://user.it.uu.se/~embe8573