[asdf-devel] Re: Make the CL syntax predictable

[Faré]

On Fri, Mar 28, 2014 at 11:33 AM, Zach Beane <xach at xach.com> wrote:
> Faré <fahree at gmail.com> writes:
>
>> On Fri, Mar 28, 2014 at 11:00 AM, Zach Beane <xach at xach.com> wrote:
>>> Faré <fahree at gmail.com> writes:
>>>
>>>> Once it's accepted that ASDF will enforce the syntax variables decided
>>>
>>> This seems more like an "if" than a "once" to me.
>>>
>> Then please argue that. I for one fully agree that the big question is
>> not about the specific defaults chosen by Dan Barlow and me in the
>> past, and possibly Robert Goldman in the future, but about whether
>> ASDF should provide a default that system author can rely upon.
>>
>> Will you argue against ASDF letting the system author fully control
>> the file type of source files, rather than it depending on a global
>> variable?
>>
>> Will you argue against ADSF letting the system author fully control
>> the encoding of source files, rather than it depending on a global
>> variable?
>>
>> Will you argue against ADSF letting the system author fully control
>> the syntax of source files, rather than it depending on a global
>> variable?
>>
>> And since you're fond of C analogies: should gcc determine the syntax
>> it uses to compile a file based on an environment variable or on
>> information fully determined by the software author in his Makefile?
>>
>> That's the high-order bit question. Let's argue it, with more than an
>> ad hominem attack.
>
> I do not want to see a system that relies on personal intercession to
> reduce the friction introduced by the things it breaks. Even if those
> things are not open source or free software projects, even if they use
> dirty, unhygienic techniques, even if they did not report promptly to
> you when a problem arose, even if they do not want your help, I do not
> think they deserve to lose.
>
> If there is no clear way to get the effects you want without breaking
> code that works today, I would prefer nothing be done until such a
> solution is clearer.
>
I don't see how this argument applies specifically against this
change. It's an argument against change in general: any change will
tautologically break some things and is tautologically fixed by a
person somewhere doing the work.

Now, mind that no one is forced to change. As far as software that I
have been maintaining goes, QRes is still using CCL 1.8, because no
one took the time to fix the concurrency issues that appear after
upgrading to CCL 1.9 or 1.10 (probably due to sloppy code on the QRes
side rather than the CCL side, but who knows - in the past CCL changes
have notably revealed Linux kernel issues). janderson is reportedly
using ASDF and libraries from at least 5 years ago. If someone is
perfectly happy with the code he has, no one wants to force them to
upgrade, and I encourage everyone to use source control and backups to
keep their builds 100% reproducible, just like we did at ITA. If
someone randomly upgrades libraries without having working versions in
source control, maybe the problem is with their lack of proper source
control, not with change happening. I promise I'm not going to hack
into anyone's machine and upgrade half the software in their back
while leaving bugs in the other half.

The question is what to do going forward regarding the change that
WILL happen, and indeed how do we reduce overall future friction. Ten
years from now, will there have been more or less friction if system
authors control syntax, or if syntax depends on the values of
variables that none of library authors, application programmers and
end-users fully control? I argue that putting system authors in full
control of their files' syntax will minimize overall friction, by A
WHOLE LOT. Making the build totally unpredictable based on changes at
the REPL and/or environment variables? Here's what causes a lot of
friction. Once again, lisp file type and character encoding are cases
in point.

Yes, there are transition costs, and yes, an overly eager transition
would increase these costs. To assess these costs is exactly why we're
having these discussions to begin with, and why Anton is running all
those tests. It's obvious now that this is not a change to happen
today, nor until all libraries in Quicklisp are fixed. And therefore,
I'm not advocating for a change before ASDF release 3.1.1, as I
previously and over-optimistically hoped. But the change needs to
happen sometime, and the sooner the better - and I'm hoping to make it
sooner, by sending fixes to each and every library that depends on
*r-d-f-f*. Unless you want to document that the user is responsible
for always ensure himself that *r-d-f-f* is bound to 'single-float
before he compiles anything, which is as far as friction goes is HIGH.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
He was a great patriot, a humanitarian, a loyal friend;
provided, of course, he really is dead.