[asdf-devel] Trying again

[Robert Goldman]

On 2/12/10 Feb 12 -4:48 AM, james anderson wrote:
> good morning;
> 
> On 2010-02-12, at 06:11 , Faré wrote:
> 
>> [...]
>>> The problem with doing the INTER-system dependencies is that I don't
>>> believe that ASDF currently has the infrastructure to do The Right
>>> Thing.  In order to do the right thing, each system would have to store
>>> with itself information about the state of the dependencies when it was
>>> built.
>>>
>> A timestamp is all you should be needing. What else do you need, really?
>>
>>> Pace Daniel H, I don't believe that timestamps on files is sufficient to
>>> do this.  We have developed an API based on operation-done-p, and I
>>> don't believe that operation-done-p is sufficient for this.  Timestamps
>>> on files is sufficient for make, but I'm not confident it's sufficient
>>> for ASDF.  At any rate, I believe that we need to go through a process
>>> of making proposals about a protocol that will do the right thing, and
>>> then move on.
>>>
>> Maybe the current timestamps in ASDF are somewhat lacking, but
>> that doesn't mean timestamps can't solve the issue. I think that
>> one timestamp per pair (op component) should do the trick, stored
>> as an alist (op timestamp) in a slot of the component.
> 
> is that not what the `operation-time` cache[1] is already there to do?
> (traverse x operation-done-p) reads as if module-level "done-p" is
> hard-coded[2] with logic, which is different than that for components in
> general, and which does not act on this cache. perhaps some protocol
> additions would work here.

One problem is that this cache does not survive across lisp sessions, so
we can't appeal to it to establish correctness when our lisp first
starts up (unless we add code to populate the cache with inferred
compilation times).

A second problem is that there are two meanings to performing an
operation on a system, and these two meanings need to be teased apart.
(I don't believe this distinction is helpful.)

One meaning is the intuitive one:  to operate on a module is to operate
on all of its components.  The second is the less intuitive tree walking
one:  there is a tree node that corresponds to operating on the module
proper, and we do the operation by  calling PERFORM on the operation and
module objects.

With respect to your point about module level done-p being hard-coded, I
agree --- I discussed this in terms of the distinction between
operation-done-p and traverse, in my earlier response to Faré.  Note
that the unhelpful dual definition of performing an operation on a
module almost forces this distinction.