[asdf-devel] Update: encoding file options version.

[Faré]

On Sun, Apr 22, 2012 at 08:48, Pascal Costanza <pc at p-cos.net> wrote:
>
> On 22 Apr 2012, at 00:01, Faré wrote:
>
>> I'd like to add :encoding now, if only because
>> if we are to ever use it, we must wait for it to be
>> in an asdf that has already made its way to all/most implementations
>> before it's considered universal enough for libraries to rely on it.
>> Whereas if we don't end up using it, it's easier to remove later.
>>
>> But you're right: I should not actively encourage its use for now,
>> except for people who know what they are doing and are ready to deal
>> with stricter dependencies and possible future change.
>
> These two paragraphs show very clearly what's wrong with ASDF (since v2.x): Experimental features are pushed to CL implementations (that mostly pick it up because ASDF has turned into a de-facto standard), instead of figuring out a way that helps the CL community to participate in having a say on what the best solutions for particular problems could be. The decision which concrete experimental feature is put into ASDF is largely in the hand of the maintainers.
>
> People who know what they are doing can _always_ go to some place and fetch the concrete experimental feature that they need. Those people _don't need_ a feature to be available in all CL implementations. The only features that should be in all CL implementations are the ones that are stable and mature!
>
Unlike the support for multiple encodings and their detection, that is
indeed experimental and included in the extension system asdf-encodings,
the hooks and defaults for encodings in ASDF are indeed mature and stable.
They add all of 68 lines to ASDF out of a current count of 4422
(versus 2011 before I took over), of which explicit :encoding
vs implicit auto-detection only add about 20 lines.
I don't think it's an excessive price.

This is a case of ASDF following the principle
"Keep things as simple as you can, but no simpler."
Encodings is one of those features that cannot be added after the fact
without either defeating the purpose or requiring wholesale replacement
of ASDF internals in the absence of proper hooks, like
upgradability, search path configuration, output translations,
around-compile capability, windows .lnk support,
a data-model compatible with a parallelizing extension (poiu),
ecl compiler mode support (native vs bytecode compiler),
logical pathnames support, etc.

> The situation before ASDF 2.x, when ASDF was not bundled with CL implementations, was much better!
>
I don't see how. ASDF 2 is fully backwards compatible in this regard, and
you can keep loading a manually installed ASDF rather than (require "asdf")
if that's what you want, including any old ASDF 1 you used to love.
Actually, UNLIKE what was the case with ASDF 1, you can load ASDF 2
on top of a previously loaded or dumped ASDF without breaking everything
(I remember sorry experiences trying hard to avoid images dumped by
common-lisp-controller).
Thus you can use the bundled ASDF to load your own version,
and that's what we now do at ITA for better version control.

Now if you have great ideas on how to enhance ASDF, we accept patches,
and I've announced many times that I was ready to retire
should someone else come forward as a maintainer.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The main reason to always choose the simplest explanation is that it leaves
least leeway for parasites to manipulate you. If you don't pick the simplest
explanation, you're being manipulated.