Re: rfc - delay the parsing of system components

Gary King writes:
> I just finished a rough cut of an ASDF overall that makes three  
> largish changes:
> 
> 1. delays the parsing of system components until needed by traverse.  
> In particular, this means that the :components clause of defsystem  
> form happens after that system's dependencies have been loaded rather  
> than when the ASD file itself is loaded.
>
> 2. rewrites traverse as a set of methods that immediately call perform  
> (rather than building up a list of perform actions that  are then  
> called in operate).

In the plan-before-execute design that ASDF's always had, methods that
implement pieces of the plan construction protocol (OPERATION-DONE-P,
COMPONENT-DEPENDS-ON, et al.) can rely on being executed before any
steps are carried out in the current run.  Since the protocol doesn't
have any solid semantics, extensions' methods can do anything, really;
executing them mid-way through execution can expose them to conditions
that are arbitrarily unlike what such methods have been written to
reason about.

> 3. does away with :do-first and moves what it did into :in-order-to
>
> The main motivation for change #1 is to be able to define new  
> operations and source file classes in a system's dependencies and have  
> them used in that systems definitions; 

The idiomatic solution for this is to load ASDF extensions in an
EVAL-WHEN at the beginning of a .asd file.  But maybe what you're after
is representing the fact that system FOO needs ASDF extension BAR, which
isn't explicit with the EVAL-WHEN solution.  If that's what you need, it
might suffice to add a slot for this to SYSTEM and to modify
PARSE-COMPONENT-FORM to hoist out the slot's initarg and do the LOAD-OP
on those extensions before looping over the components.

> ... the main motivation#2 was #1: it does no good to delay parsing of
> the defsystem form if traverse has to complete the parse before
> anything else happens!. As for #3, while doing three things at once is
> just very human (and besides, it made #2 easier).
> 
> I've got several hours of work left cleaning up loose ends and moving  
> restarts and with-compilation-units around into better places.
> 
> What I'd appreciate is any high-level feedback about the idea of these  
> changes and whether or not I've missed some horrible interaction that  
> nullifies the whole direction. I hope to post the suggested changes  
> later in the week.

I think #2 is an at-least-in-theory incompatible change.  It might not
break anything in the wild, but that can't be known in advance.  It
might also lead to a better defsystem than ASDF, but I'm not sure that
ASDF should be breaking compatibility with itself at this point.

--
Richard

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/