Hi,
Can anybody recommend a good Lisp (static) code analyzer?
It should support both multiple readtables and backquotes.
I extensively searched the web, but unfortunately to no avail.
Your help is greatly appreciated.
bye,
Ranco
From: Tim Bradshaw
Subject: Re: looking for advanced code analyzer
Date:
Message-ID: <ey3lm8828oz.fsf@cley.com>
* Ranco Marcus wrote:
> Can anybody recommend a good Lisp (static) code analyzer?
> It should support both multiple readtables and backquotes.
> I extensively searched the web, but unfortunately to no avail.
What are you trying to do? Static analysis is almost impossible to do
for Lisp (in fact, it is impossible, but it's probably possible to get
close for programs that don't do anything too lisp-like).
--tim
>> Can anybody recommend a good Lisp (static) code analyzer?
>> It should support both multiple readtables and backquotes.
>> I extensively searched the web, but unfortunately to no avail.
> What are you trying to do? Static analysis is almost impossible to do
> for Lisp (in fact, it is impossible, but it's probably possible to get
> close for programs that don't do anything too lisp-like).
What is static analysis, and (briefly) why is it impossible?
Thanks,
joelh
Joel Ray Holveck <·····@juniper.net> writes:
> What is static analysis, and (briefly) why is it impossible?
Think whole-program analysis.
The dynamic nature of Lisp precludes a lot of the assumptions you
could derive from whole-program or static analysis. For example,
optimizing Lisp compilers are free to perform analysis of code within
the boundry of a function call, but not across them.
Of course, all bets are off if you are using a "delivery" only Lisp
compiler like the moribund Chestnut Lisp-to-C translator or Jeffrey
Siskind's Stalin.
From: Tim Bradshaw
Subject: Re: looking for advanced code analyzer
Date:
Message-ID: <ey3heiw0zue.fsf@cley.com>
* Joel Ray Holveck wrote:
> What is static analysis, and (briefly) why is it impossible?
I think my response was wrong. I had assumed (from what the person
wrote, but also from my prejudices) that what was meant was an
*external* program (presumably in Lisp) which would look at the code
and deduce various things about it, *without* loading it. I think
that this is sufficiently hard as to be not interesting - there are
just so many things in large Lisp programs which make it hard to
understand them (or even read them) `cold' like this. For instance
almost the fist thing my system does when being loaded is define a new
version of DEFPACKAGE which supports `conduit packages'. After that
point, unless the analyser understands that code (which essentially
means that it needs to load it), it won't understand the package
structure of the program, and thus it won't really understand the
program at all. And this is one small part of the problem such an
analyzer has.
I guess the underlying problem is that, for Lisp programs, there are
*many* places during the reading and compilation of the program where
completely arbitrary Lisp code can run (read macros, macros, compiler
macros, EVAL-WHEN and so on). And, worse, for large programs, these
facilities are used fairly frequently.
So essentially the only useful way to understand a Lisp program is to
actually read and compile it, and rely on instrumentation in the Lisp
system to tell you about it. And this is, indeed, the approach most
Lisp systems take - to load up the who-calls database, you load the
system, and so on.
However, I think that what was actually meant by static analysis (or,
anyway, a better meaning than what I'd assumed) is the kind of
analysis you can do *just* by reading and compiling the program. So,
for instance, you might find out stuff about types, or about the call
graph, or about argument count mismatches and so on.
For a dynamic language like Lisp this is still impossible in the
idiotic `if my program compiles it will not get runtime errors' sense
in which some of the more foolish static-language people seem to
believe. But good compilation systems will obviously tell you
everything they can, and this can be very useful.
Finally, I think that what was leading me astray was that for really
static languages, you can do the latter using the former, because the
language does not allow the kind of incremental redefinition of itself
that Lisp does, so an external tool can understand it.
--tim
Tim Bradshaw <···@cley.com> writes:
> What are you trying to do? Static analysis is almost impossible to do
> for Lisp (in fact, it is impossible, but it's probably possible to get
> close for programs that don't do anything too lisp-like).
If you believe the CMUCL documentation, its compiler can perform
various kinds of fancy block compilation which opens the door for
static analysis of potentially large call-graphs.
Unfortunately, this feature seems somewhat unique to CMUCL (although
lots of in-line declarations should have the same effect on other Lisp
systems).
[I accidently replied to the author instead of to the group]
> > Can anybody recommend a good Lisp (static) code analyzer?
> What are you trying to do?
I have a large piece of Lisp source code of an interpreter (hence the
different readtables)
and I would like to use an analyzer to report on possible errors such as
unused variables or functions, function arity errors, perhaps naming
differences. Also, a graph illustrating the system's structure would be very
nice, but I don't know if this is possible.
> Static analysis is almost impossible to do for Lisp (in fact, it is
impossible, but it's probably
> possible to get close for programs that don't do anything too lisp-like).
Exactly, I suspect it should be possible to extract at least some
information. However, if the system uses to much dynamic features (something
like explicit eval ?), things will get more and more complex.
ciao,
Ranco
"Ranco Marcus" <··········@student.unimaas.nl> writes:
> [I accidently replied to the author instead of to the group]
>
> > > Can anybody recommend a good Lisp (static) code analyzer?
>
> > What are you trying to do?
>
> I have a large piece of Lisp source code of an interpreter (hence
> the different readtables) and I would like to use an analyzer to
> report on possible errors such as unused variables or functions,
> function arity errors, perhaps naming differences. Also, a graph
> illustrating the system's structure would be very nice, but I don't
> know if this is possible.
Just compiling it with CMUCL will do quite a lot of these checks (you
might have to play with (declare (optimize ...)) a bit).
I imagine other lisps might do similar checks at compile time, but
don't actually know...
Cheers,
M.
--
nonono, while we're making wild conjectures about the behavior
of completely irrelevant tasks, we must not also make serious
mistakes, or the data might suddenly become statistically valid.
-- Erik Naggum, comp.lang.lisp
On Fri, 19 Jul 2002 14:16:01 +0200, "Ranco Marcus"
<··········@student.unimaas.nl> wrote:
> differences. Also, a graph illustrating the system's structure would be very
> nice, but I don't know if this is possible.
You may try Mark Kantrowitz's XREF tool, which is part of the portable
Common Lisp utilities available at the CMU Common Lisp Repository.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
>>>>> "Paolo" == Paolo Amoroso <·······@mclink.it> writes:
Paolo> On Fri, 19 Jul 2002 14:16:01 +0200, "Ranco Marcus"
Paolo> <··········@student.unimaas.nl> wrote:
>> differences. Also, a graph illustrating the system's structure would be very
>> nice, but I don't know if this is possible.
Paolo> You may try Mark Kantrowitz's XREF tool, which is part of the portable
Paolo> Common Lisp utilities available at the CMU Common Lisp Repository.
A long time ago, I also wrote a small hack that took the output of
XREF and produced a graphical display of the call structure. I used
Garnet for this. If you're interested, ask, and I'll see if I can't
find it.
Ray