On Thu, Oct 12, 2017 at 6:53 PM, Stelian Ionescu sionescu@cddr.org wrote:
On Thu, 2017-10-12 at 13:03 -0500, Robert Goldman wrote:
That may be, but it was unfair to get angry at the ASDF maintainers about this. This is just a pre-existing error that was *manifested* because of a change in ASDF. It's not our fault that this error appeared, it's not our fault that the puri library is no longer maintained, and we can't be expected to avoid releasing improved versions of ASDF because there exists buggy, unmaintained code in Quicklisp.
No it's not your fault, but I think it would be a very sensitive idea to avoid annoying ASDF users, simply for practical reasons, because you'll find yourself with people who fork or refuse to update ASDF.
Well, in this case, it was a combination of things that are not our fault, and things that are. So my apologies for the things that were my fault.
Something more useful would be to:
- introduce the notion of ASDF compilation options, as a set of key-
value pairs which control different compilation modes or effects
ASDF already kind of has that, as keyword arguments to operate. They was a bit of a cleanup in ASDF 3.3.0 already: the arguments are not passed blindly into non-sensical arguments to the operation class anymore, and are now well-defined. Thus they can now be used the way you propose.
- make the new strictness modes, like preserving the readtable, depend
on those toggles, but upon introduction the default should be perfect backwards-compatibility, even if that is something you consider broken
Agreed. Any new strictness should be added cautiously and slowly, disabled by default or adding only a (style-)warning. In this case, the strictness was added by accident (because the forms that prevented the strictness were victim of a refactoring I botched while adding a different feature, and the strictness was only added in a corner case for which I had no test, but just added one now).
- blog about the fancy new way toggle and explain why it's better to
use it than not
Will do, if I keep hacking on it.
- let the libraries' users nag the developers to change the code to be
compatible with the new strictness checks
Maybe. Historically, the main problem has been unmaintained libraries.
- wait a couple of years (at least) until you see that most of
Quicklisp libraries have been ported to the new way of doing things and if that happens maybe consider turning it on by default. In that case, announce it publicly
Yes, we've typically waited for a year or two before we added any new strictness (e.g. everything is now UTF-8 by default).
- if adoption didn't happen, keep it disabled happily knowing that you
can always turn it on in your company's internal projects.
This has happened in the past, e.g. for properly catching deferred warnings. Most users never bothered to do it, maintainers never bothered to fix their libraries, etc. Maybe with more outreach they would, but I'm kind of burned out with CL right now.
This is more or less how we do things at work. It has a certain amount of overhead but it gains you good will from the community; on the other hand enabling things by default, and on a short notice, only makes you seem like you're imposing your preference on everybody else just for the sake of it. I think it's better to let things sink in and allow the users of ASDF to come to a consensus, although that's a slow process.
I've tried very hard not to do that this time. It was a bug. (Unlike four to five years ago, when I learned the hard way not to push too hard the deferred warning support or the syntax-control branch; the latter just came back and bit me.)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Amateur bureaucrats are often even worse than professional bureaucrats. — John McCarthy