Is anyone aware of a package that will analyze code in terms of style? For
example, given the function below, it would spit out the comment, "Don't you
really want to use MAPCAN instead of reinventing it?"
(defun collect-eggs (chickens)
(if (null chickens)
nil
(nconc (lay-eggs (car chickens))
(collect-eggs (cdr chickens)))))
It might also identify a host of other things. An experienced Lisper, if he
is paying attention, would not need this sort of thing, but it might be
useful for someone learning the language. Mostly, though, it would just be
fun to write ...
Cheers,
Glen
Glen Foy <······@toast.net> writes:
> Is anyone aware of a package that will analyze code in terms of style? For
> example, given the function below, it would spit out the comment, "Don't you
> really want to use MAPCAN instead of reinventing it?"
>
> (defun collect-eggs (chickens)
> (if (null chickens)
> nil
> (nconc (lay-eggs (car chickens))
> (collect-eggs (cdr chickens)))))
>
> It might also identify a host of other things. An experienced Lisper, if he
> is paying attention, would not need this sort of thing, but it might be
> useful for someone learning the language. Mostly, though, it would just be
> fun to write ...
>
As far as my understanding goes, this is hardly possible at our stage of
AI programming. Of course something simple can be written without much
difficulty (something that warns you about using eval() or perhaps even
suggest that recursive functions be rewritten with tail recursion), but
creating something that would behave like you said is, AFAIK, way beyond
the capabilities of current AI. This is because theoretically there are
infinite ways to solve any problem, which means that for the style
analyzer to warn you about redefining some standard function it would
have to _understand_ the code as well as an experienced Lisper. Such
understanding implies almost the true meaning of AI, an intelligence that
is not programmed to react to some pattern, but instead _think_ by
itself.
Regards,
Richard
--
Richard Krushelnitskiy "I know not with what weapons World War III will
rkrush (at) gmx.net be fought, but World War IV will be fought with
http://rkrush.cjb.net sticks and stones." -- Albert Einstein
From: Christopher C. Stacy
Subject: Re: Automated Style Analysis
Date:
Message-ID: <u8z3oxv7b.fsf@dtpq.com>
Check out the Programmer's Apprentice papers from the early-mid 1980's.
In article <····················@toast.net>,
Glen Foy <······@toast.net> wrote:
> Is anyone aware of a package that will analyze code in terms of style?
The compiler from Symbolics (-> Genera or OpenGenera) has
extensible compiler style warnings.
Glen Foy <······@toast.net> wrote in message news:<····················@toast.net>...
> Is anyone aware of a package that will analyze code in terms of style? For
> example, given the function below, it would spit out the comment, "Don't you
> really want to use MAPCAN instead of reinventing it?"
Such a program could be implemented with a collection of recognizers
and explainers. Each recognizer would look at the program to see
where it recognized a particular pattern, such as usage of an idiom
that would be better implemented with mapcan. If it recognized it,
the corresponding explainer would explain that particular problem and
how that particular code fit that pattern.
The hard part is in how many recognizers and explainers you would
need. Each one could be implemented in a relatively short time, but
you might need thousands, or even millions of them, depending on how
sophisticated you want the style checker to be.
If more than one pattern of code can be replaced by mapcan, you can
simply implement a different recognizer/explainer pair for each such
pattern.
Some much more sophisticated ways to do it are interesting to ponder,
but not necessarily feasible yet.
··········@mailandnews.com (Software Scavenger) writes:
> The hard part is in how many recognizers and explainers you would
> need. Each one could be implemented in a relatively short time, but
> you might need thousands, or even millions of them, depending on how
> sophisticated you want the style checker to be.
what? why can't we map everything to bottom?
(sleep dep joke, sorry.)
in any case, scaling problems can be pushed to the internet... the problem is
that the net effect of widespread autofactorization would be loss of jobs for
tinkertoy programmers, so uptake of this would have to be forced. but once
it's in place, first-order programming is as good as dead and buried. one can
dream...
thi
In article <···············@glug.org>, Thien-Thi Nguyen <···@glug.org>
wrote:
>··········@mailandnews.com (Software Scavenger) writes:
>
>> The hard part is in how many recognizers and explainers you would
>> need. Each one could be implemented in a relatively short time, but
>> you might need thousands, or even millions of them, depending on how
>> sophisticated you want the style checker to be.
>
>what? why can't we map everything to bottom?
>
>(sleep dep joke, sorry.)
>
>in any case, scaling problems can be pushed to the internet... the problem is
>that the net effect of widespread autofactorization would be loss of jobs for
>tinkertoy programmers, so uptake of this would have to be forced. but once
>it's in place, first-order programming is as good as dead and buried. one can
>dream...
Another way of thinking about it is that you don't need to solve the
whole problem, you just need to solve enough of the problem to make the
auomated analysis worth doing. There are plenty of optimizing compilers
out there, for example, that don't do every single possible optimization.
As people built recognizers for additional patterns they'd be easy
enough to factor in. So perhaps the question is what the base set of
useful nagging points looks like and how long it would take to build a
scanner that recognized them...
paul