[E] new compiler error re: SET-DISPATCH-MACRO-CHARACTER

[Faré]

On Thu, Oct 12, 2017 at 6:53 PM, Stelian Ionescu <sionescu at 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