uiop non-problems

Faré fahree at gmail.com
Sat Oct 21 02:39:19 UTC 2017


On Fri, Oct 20, 2017 at 6:09 PM, Anton Vodonosov <avodonosov at yandex.ru> wrote:
> Fare, what do you mean by "encoding" of nil and t?
>
In ASDF 3, the function stamp< compared to timestamps that are either
real numbers or booleans, where booleans represent the infinities on
the real line.

In ASDF 2.27 to 3.2.1, NIL represents -infinity and T represents +infinity.
In ASDF 3.3.0, NIL represents +infinity and T represents -infinity,
which allows ASDF to directly use safe-file-write-date /
get-file-stamp results without inversion of convention all over the
place.

Problem is: since stamp< is defined in UIOP and used in ASDF, a
discrepancy between the two breaks ASDF. But one of the avowed
purposes of UIOP is to be used outside (or without) ASDF, and it
therefore is very important for UIOP to be backward compatible and not
make such changes, *even* if no one but ASDF uses the function. A
version of UIOP ahead of ASDF *is* a valid supported use case, that
Quicklisp exercises for us. It was thus a bug for me to do that, and
it was my big mistake to fail to think about the consequences
properly.

The solution I have in !87 (which is included in the candidate test
branch I'd like you to test) is for ASDF 3.3.1 to rename stamp< to
timestamp< (and so on for related functions) in uiop/utility, so that
the new convention comes with new names. Thus, when an old ASDF
3.[012] loads a new and the new functions don't overwrite the old ones
(as they do with UIOP 3.3.0), but go into new symbols, while the old
symbols get uninterned but keep their bindings and the old ASDF keeps
using that.
https://gitlab.common-lisp.net/asdf/asdf/merge_requests/87

NB: this is still not as backward compatible as can be. Here is a
contrived scenario where the solution requires to keep defining the
old functions as well as the new ones: when you upgrade ASDF from
3.1.5 to 3.2.1, but upgrade UIOP to 3.3.1 instead of 3.2.1. I don't
think this is a likely scenario or one we should support, and it won't
normally happen with Quicklisp, since whatever asdf source directory
you use, outside of Quicklisp, will include its own UIOP, that will
take precedence over the one in Quicklisp. To upgrade ASDF to a
relatively old version yet UIOP to a newer one, you would really have
to do it on purpose, and then you would deserve to lose. I don't
believe we ought to support this scenario, at which point we don't
have to keep defining the old functions.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Gauss, when asked how soon he expected to reach certain mathematical
conclusions, replied that he had reached them long ago, all he was worrying
about was how to reach them! [Karl F. Gauss (1777-1855), German mathematician]



More information about the asdf-devel mailing list