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

[Faré]

On Wed, Apr 18, 2012 at 10:24, Douglas Crosher <dtc-asdf at scieneer.com> wrote:
>
> A revised version of ASDF replacing the system definition :encoding support with support for reading the encoding from file options
> is now available at: http://www.scieneer.com/files/asdf.lisp
>
I thank you for your interest and your code, Douglas; however,
unless you're willing to bear the curse of ASDF maintainership
(which I hope you're not going to claim lightly, for I will yield it happily),
I'd appreciate it if you tried to do things my way:
for now, I'd like encoding autodetection to be done in the
asdf-encodings system.

I understand this may be frustrating for you,
especially since for some reason you truly hate the idea of a
:encoding specification
(though I'm not sure I understand why).
However, keeping the encodings support separate, even temporarily, has
several advantages:
* it allows this particular fast moving code to evolve and be refined
without burdening asdf,
 and without having to cast in stone design choices made before we
fully understand the issues.
* it keeps ASDF small for most people, yet allows the extension code
to grow big.
 For instance, not only can the extension itself can have many long
files and depend on many libraries,
 it is conceivable that a far future version of asdf-encodings
 could translate on the fly between encodings not supported by an implementation
 and utf-8 as supported by the implementation (this would require
additional hooks in ASDF).
* It fits the minimalist design goal of ASDF, whereby
 ASDF tries to contain only the bare minimal to build Lisp software,
 together with enough extension hooks so that desired features can be
built on top.
 I believe this has been a relative success so far, with extensions including
 CFFI-GROVEL, HU.DWIM.ASDF, POIU, ASDF-DEPENDENCY-GROVEL,
 plus various things used at ITA that I know, and possibly more used
other places that I don't.

And yes, if and when we reach some stable, widely accepted
design and implementation in asdf-encodings,
it will be time to consider integrating it into ASDF itself.
However, unlike the case of the source-registry and the
output-translations layers,
where bootstrapping was an issue that made keeping those layers
separate a self-defeating non-starter,
I believe we can afford (at least for now) to require people who need
non-standard encodings
to load asdf-encodings separately and to merge that layer at a later
date (if ever).

As for the specific code you propose,
* I asked on #emacs pointers to how Emacs identifies coding.
 I documented the results in comments in asdf-encodings.
 The Emacs way differs from your code in various ways.
 If we are going that way,
 is there any reason not to "just adopt" the Emacs code?
* Does it make sense for a file to have a UTF-16LE header that
 specifies coding: koi8-r ? I don't think so.
 Or a pun file that in UTF-16BE says it's UTF-16LE,
 and the other way around (or a longer circuit)?
 I think your algorithm tries both too hard (as in this case),
 and too little (as in cases where Emacs finds a coding and your code doesn't).
* All in all that doesn't mean your code is bad,
 but that probably means we should experiment with it and tweak it,
 before we declare ourselves satisfied with burning it into ASDF
 (which is somewhat less easy to upgrade than a casual library).

—♯ƒ
I'm a polyatheist — there are many gods I don't believe in. — Dan Fouts