[asdf-devel] The future of ASDF (was logical pathnames)

[Robert Goldman]

On 3/31/10 Mar 31 -12:25 PM, Juan Jose Garcia-Ripoll wrote:
> On Wed, Mar 31, 2010 at 3:46 PM, Robert Goldman <rpgoldman at sift.info
> <mailto:rpgoldman at sift.info>> wrote:
> 
>     Lisp development --- at least for people like me --- is primarily an
>     interactive process, and this is why building and loading/executing are
>     /inextricably/ linked.
> 
> 
> Please note that image driven development is NOT the only paradigm that
> exists in the lisp world. ECL works very well at creating standalone
> executables from compiled files, but it can not dump binary images of
> its full environment because that can not be implemented portably across
> all platforms we support -- specially not when one mixes shared
> libraries, different memory management paradigms (C, lisp, C++,
> operating system) and other stuff.
> 
> The problem is that people who are used to think on image driven
> development are those who have pushed forward also the development of
> ASDF as it is right now and indeed, with this mentality of an image
> where everything is loaded there is no distinction between placing
> things an the *.asd file or in the compiled files. In other words, the
> flexibility has propagated to the users with an absolute lack of
> organization in how things are done right now.
> 
> I even found out some libraries that ave problems in the dependencies,
> because the image driven development has side effects, such as the
> creation of macros, etc, which persist beyond compilation and can lead
> the developer to think that a load-op succeeds when it will not in a
> fresh new image.
> 
> What I am trying to say is that ASDF "as is" need not stop working. We
> may keep ASDF as a large database which you can use to power interactive
> development and automatic recompilation as things change. I believe this
> is a wonderful feature it is implicit in the long email I wrote.
> 
> However, ASDF has to seek other fields and in particlar enforce a
> discipline such that existing systems can be built from scratch using
> different paradigms -- for instance, building standalone programs from
> individual components.
> 
> In other words, the image-driven system can not be the model on which
> ASDF is built and it can not be part of its semantics because it
> prevents other models, but it has to remain an option for those who want
> to use it.
> 
> I strongly believe that both things can and should coexist.

With all due respect, this seems contentious and unsupported.  I don't
see any particular reason to believe that a tool for the coherent
maintenance of a long-running image would also be a good fit for more
conventional development.

There are already tools for the non-image-driven development.  If ECL is
not aiming at image-driven development, maybe a tool like make, or make
+ autoconf would be a better fit.

That said, if you wish to try to make ASDF work for conventional
build-and-exit system construction, and that doesn't break ASDF for
image integrity maintenance, more power to you!

Best,
R