[asdf-devel] 2.014.8

[Robert Goldman]

On 4/23/11 Apr 23 -5:03 PM, Zach Beane wrote:
> "Robert P. Goldman" <rpgoldman at sift.info> writes:
> 
>> With all due respect, it's not a matter of pushing people to follow a
>> convention. The code and documentation specify a data type and the
>> interpretation of its values.
> 
> The ASDF code didn't actually mandate a string type for the slot until a
> couple minor versions ago, and that's what's causing the compile-time
> failure on SBCL (and only then at safety 3). Code that actually cared
> about the version would have failed at runtime. Clearly, at the moment,
> nobody cares - it would be nice to defer the problem until someone
> starts caring.

I don't actually agree with this claim.  The correct functioning of
version-satisfies has always required a string type (and a very
specifically constructed string type) for this slot, as far as I can
tell, certainly as far back as 2001.

We never /checked/ before, but that doesn't mean non-specially
constructed string values were /ever/ valid.  That would be like saying
that we have never worried about using English versus metric units in
our navigation software to date, so it's ok....

That said, I agree that it's unrealistic to refuse to load systems that
have non-conforming version values, simply because this is so prevalent
in the wild.  But I don't agree that this is an OK state of affairs.
Killing the version slot would even be better than offering it as
supporting a version satisfaction check that it cannot support.

I think the best compromise between realism and ideals will be to
evaluate any version specifier that's present (not evaluating it seems
to me to be unproductive purism --- forcing #. makes ASDF undesirably
less declarative --- and evaluating strings won't break anything not
already broken), catch errors that arise when evaluating, then check the
results for being well-formed period-separated strings.  Bad values
won't do anyone any good, so just ignore them and raise a warning.

The warning will encourage developers to provide well-formed version
specifiers, without breaking the load of systems with bad ones.

We may need to handle the warnings (by printing them and continuing), or
make them of some subtype of STYLE-WARNING if that is necessary to keep
some implementations from aborting ASDF load upon warning.  If a normal
warning would break loading, I'd suggest we use a new subtype of
STYLE-WARNING.

Ideally, this would evolve from a warning towards a TYPE-ERROR, but
there's no hurry.

In sum, I believe the principle should be to try to help, or even
enforce, having good values in one's data structures, but that the
principle must come second to not breaking the community library
infrastructure.  I also believe that the above policy would be a
reasonable compromise.

Best,
R