[asdf-devel] New ASDF maintainer sought

[Pascal J. Bourguignon]

Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> writes:

> On Wed, Sep 22, 2010 at 8:37 PM, Pascal J. Bourguignon <pjb at informatimago.com> wrote:
>
>     > No. Why? I mean, the separate components are bundled into a
>     > single asdf.lisp and this process is automated (make -f
>     > GNUmakefile asdf.lisp). There is no new testing burden. I am
>     > just advocating for some common sense in the ASDF codebase,
>     > organizing it in a readable and separated way.
>    
>     This is an alternative, indeed.
>    
>     asdf.lisp: $(ASDF_SOURCES)        clar asdf.lisp $(ASDF_SOURCES)
>
> Indeed, eventually one should move my GNUmakefile line from using
> sed to using some Lisp implementation for repackaging asdf.lisp,
> ensuring a version number, etc.
>
> Incidentally, I am still amazed at how people here find a 4k source
> file manageable at all. No organization, functions spread throught
> the file, no clear navigation structure... If I have a directory
> with 10 small files, each one devoted to a separate and clear task,
> I know where I have to go to edit things for that particular topic.

Some early C programmers even put one function per file.  I guess it
can be useful if you use vi...

But when you have a smart editor such as emacs, with at least a good
search function, or even a find-tag feature, it doesn't really matter
where your functions are stored.  Actually, file management should be
left up to the system and the programmer should not care about the
storage of their functions.  Like in Smalltalk for example.  So
instead of dealing with a linear sequence of functions, you can rather
work on a tree or graph of functions, and navigate from one to the
other directly.

That said, I too like to have things gathered up in a somewhat
organized way, so that I may browse and revise the code in a
meaningful way.  But there are probably better ways to do it.  In
particular when you consider multiple dispatch in CLOS, you could have
several ways to sort out the methods, depending on what you're doing.
So it would be better to let the tools gather the code
dynamically. (eg. get all the methods applying to objects of a given
class, or get all the functions in the call graph rooted from a given
function, things like that).



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/