[asdf-devel] Trying again

[james anderson]

On 2010-02-12, at 17:17 , Robert Goldman wrote:

> 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).

one might conclude, that the (cache x done-p) semantics should be  
defined such that they yield the same results for respective external  
states across system instantiations.

>
> 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.)
[? this parenthetical sentence and the preceding clause can be read  
such that they contradict each other.]

>
> 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.

once one has arrived to the point, where each "component" can concern  
internal, intrinsic performance, that of constituents, and that of  
requirements, one is able to consider for which component classes  
which combinations of (internal x constituent x requirement)  
performance have which effects on completion status.
yes, that is an essential step.

>
> 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.

yes, your #3 in that earlier message, suggests that you may also have  
reached the point, above.