[asdf-devel] ASDF traverse changed behavior?

[Robert Goldman]

On 3/17/10 Mar 17 -5:36 PM, Faré wrote:
> Dear friends,
> 
> let's please focus on the technical problem and drop the nagging. We
> all want the same thing: an ASDF that works for everyone, including
> ECL, and ECL is not to be considered a mere client, but an integral
> part of ASDF. And we all suffer from the same breakages that waste our
> time. And so let's talk about solutions rather than about blame.
> 
> From Juanjo's and Robert's descriptions, it seems to me that the
> TRAVERSE API could be improved to satisfy everyone.
> 
> Maybe it's a matter of splitting TRAVERSE into parts, and allowing
> these parts to recurse or not on dependencies depending on various
> flags.
> 
> I think the main issue is being able to recurse within the scope of
> some system or module or not: we want to be able to tell TRAVERSE
> "here's a predicate or description that tells how far you go", maybe
> recording on the side a queue of things that haven't been traversed
> but need to be done nonetheless.
> 
> So, traverse would take as an additional argument some specifier for
> the scope of the traversal (system, module, predicate, etc.), and
> return multiple values: the list of inside ops (fully recursed into),
> and the list of outside ops (not recursed into).
> 
> Would something like that help?

For all TRAVERSE's failings, I'd prefer not to see the API complicated.
 I'm inclined to think it's already a bug that one has to understand
TRAVERSE as much as one does.  Also, if we expose TRAVERSE, we are more
nailed into it.  You and I have already discussed the fact that it would
be nice if we could fix the INTER-system dependency problem.  If we
expose the TRAVERSE API, fixing this kind of bug will only get harder,
because the slice we expose as supported will be wider.

Finally, I'm concerned that this would cause an explosion in our testing
needs.  If we have N different TRAVERSE configurations, we'll have to
test them against N different situations.

How about my suggestion that we allow some operations to be defined as
system operations that do not recurse into their children?

Would that solve the problem?

Note that that means traverse will visit those nodes, but we have not
promised anything about the behavior of traverse, nor about its return
value.  To the limited extent that we can say that ASDF specifies
anything, I think one could say that it tells you that it will do all
the operations in its plan, and it actually tells you you need to define
them in some cases to be No-ops.

best,
r