Re: clisp - general interest in code cleanup

[Pascal J. B. <pj...@in...>]

<Joe...@t-...> writes:

> it in a positive way) view on what's actually important. As a result,
> those days, programmers view code in a tinier window than when I
> started computing on a 9" screen over 30 years ago.
> That's no progress to me!

LOL. Indeed.

>> Something like the Smalltalk
>> code browser: there's no notion of file then.
>
> It works nicely for Smalltalk, because unlike C or Common Lisp, the
> semantics of a method body does not depend on a myriad of definitions
> that appears in lexical order before it in the source file.
>  - No macros nor any variations to the syntax;
>  - Nothing like operator precedence (except unary operators);
>  - class and instance variables are one window away.
> Hence IMHO, any parallel is not applicable.

Reader macros can be treated as a dependency (at the form level).

But you're right that a requirement for an IDE nowadays is to include an
execution environment where the source being edited is also compiled and
loaded.  In modern Java IDE and C/C++ (with clang) IDE, they compile the
source at least.  In lisp we'd have to add the run-time environment, to
be able to identify correctly more elements, notably if we don't have a
global static analyser.  This is what slime does.

Granted it's possible to write lisp programs that will fight even this
step, but remember that macros and reader macros should be idempotent,
so there's already some provision in the standard to help IDE there.
Also, with the promotion of ASDF, package and system set up has become
more declarative (rather than procedural); modern lisp code is more
compatible with an IDE treatment.


> In summary, the 'function at a time' might work with programs with
> strong locality, e.g. tree structured. But not when you need to
> implement a collection of event handlers. Those hide the flow and
> ordering of messages and calls -- in Smalltalk too.

Indeed, I had such an example in a recent Android program I had to
maintain; it sent events to communicate between modules (assumedly on
different threads).  This kind of dependency could also be taken into
account by the IDE and it could provide navigation helpers, either
because (as in the case of this Android program) it uses a "standard"
communication mechanis, or because the programmer could declare such
dependencies to the IDE. Notably in lisp, we have the advantage of using
symbols that can be easily identified across modules.  Navigating to
uses of a given symbol could be all that is needed for the basic
feature.


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