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

[james anderson]

On 2010-03-31, at 15:46 , Robert Goldman wrote:

> By and large I agree with Juanjo's statement of principles, but I  
> would
> like to discuss the reason /why/ ASDF is different from tools like  
> Autoconf.
>
> Lisp development --- at least for people like me --- is primarily an
> interactive process, and this is why building and loading/executing  
> are
> /inextricably/ linked.
>
> It is, IMO, /not/ a handicap that ASDF performs both building and
> loading tasks, because Lisp software is not like conventional  
> software.
>
> In particular, this apparent duality ceases to become a source of
> confusion/dismay, if one stops thinking of "building" and "loading"  
> and
> thinks instead about maintaining the integrity of a running lisp  
> image.
>
> Building and loading are just pieces of that integrity maintenance  
> process.
>
> I am with Juanjo in wanting to see the process of integrity  
> maintenance
> become more declarative, and less cluttered with arbitrary procedural
> code.  But I don't think that decoupling building and loading is
> particularly desirable in general.

i am at a loss as to how it would be possible with the level of  
information in an asdf system definition.
i admit there is this class named asdf:compile-op, but i have never  
made an explicit reference to it.

if the system is small enough, compilation speed is sufficiently  
extreme that there is no case to track internal component dependencies.
for systems which find themselves with thousands of load->compile  
dependencies, the only hope is for progress in dvm's direction.

every production lisp can save an image. maybe there's a commercial  
perspective which would see value in versioned fasl components, but  
it i have yet to.


>
> For an extreme perspective on this issue, I'd encourage interested
> readers to look at Drew McDermott's paper on his integrity maintenance
> approach based on arbitrary chunks of code (a finer granularity than
> source files), where, for example, one can define dependencies  
> needed to
> compose a hash table, so that its correctness (integrity) can be
> restored when data structures on which it depends are mutated:
>
> http://cs-www.cs.yale.edu/homes/dvm/papers/lisp05.pdf

ok, but it leaves me wishing even more for the paper which really  
really attends to just the "what".

>
> This is admittedly an extreme, but it shows a purpose that systems  
> like
> ASDF can serve --- maintaining the integrity of a running lisp image
> over extremely long periods of time.

it's not extreme. it is just an unfortunately neglected direction.