[asdf-devel] Unexpected behavior when loading different versions of a system

[Daniel Herring]

On Fri, 2 Sep 2011, Robert Goldman wrote:
> On 9/2/11 Sep 2 -12:25 PM, dherring at tentpost.com wrote:
>>> [Indeed, Faré and I had in the past discussed the possibility that when
>>> a new system definition for an existing system is loaded, we should
>>> simply regard the entire system as "dirty" and always rebuild everything
>>> in it.]
...
>>
>> In a serial CL process (all files loaded/compiled by the same image), the
>> presence or absence of a file may greatly affect all files visited after
>> it.  Thus given this interactive image model, I don't think any simple
>> option will work in all cases.  The current behavior is reasonable (modulo
>> where the files are found).
>
> I fundamentally disagree about this.  For two reasons:
>
> 1.  Correctness over convenience:  It is more important to restore
...
> 2.  The model is fundamentally busted.  If you reload a system file, the
> data structures in ASDF are in a deeply wrong state.  The SYSTEM objects
...
>>
>> Thus, I wouldn't force a rebuild when the system definition changes, but a
>> rebuild might be deserved when the source location changes.
>
> The bad behaviors are not limited to bad behaviors from location
> changes.  If you change the membership of the system, but the system is
> in the same location, that can introduce corruption, as well.
>
> I don't see a way to keep correctness here and maintain the current
> behavior.

I'll try rephrasing my point.  Under the interactive image model, 
recompiling the whole system provides only slightly stronger guarantees 
than not.  State changes since the initial compilation may adversely 
affect the recompile, and downstream systems also face unknown issues. 
Thus I wouldn't force a recompile unless there was reason to believe the 
source files had changed (ASDF's default behavior).

For example, consider the difficulty ASDF has in bootstrapping new 
versions of itself.

Now, if your argument is that ASDF's internal state is completely 
unreliable after a system change, and the cleanest way to fix it is the 
nuclear option, then that is a strong argument for recompiling everything 
in the project.

I agree with Fare that XCVB addresses some of these issues.  Don't 
understand it enough to say by how much (still todo... sigh).

Later,
Daniel

P.S.  I tend to agree with the "recompile cycles are cheap" argument, but 
it would be nice to have an option for people to skip a full recompile 
caused by minor system definition changes.  It would be very useful when 
doing minor tweaks on large systems.