On 4/23/11 Apr 23 -5:03 PM, Zach Beane wrote:
"Robert P. Goldman" rpgoldman@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