On Wed, Apr 18, 2012 at 10:24, Douglas Crosher dtc-asdf@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