Abstract: I think requiring a few marginal hackers doing weird things to specifiy :encoding :default is a small price to pay for everyone to be able to specify their encoding in a portable way, with a sane default that is already almost universally accepted (i.e. :utf-8).
On Sun, Apr 8, 2012 at 07:31, Douglas Crosher dtc-asdf@scieneer.com wrote:
The portable-hemlock is still maintained and was updated a few months ago to avoid the use of non-ascii characters in the source so it builds cleanly with UTF-8 as the input external-format. The code is not in great shape, but is being improved. See: http://gitorious.org/hemlock/pages/Home
Oh, I hadn't noticed this new page for hemlock. Is CMUCL using the portable hemlock these days, or still including its own?
Even if you get all the quick lisp projects converted to be UTF-8 clean, this still represents a subset of ASDF users. I wish you would reconsider these changes to ASDF because I fear it is divisive.
Well, I recognize that not all code is in Quicklisp and that there is a need for a backward compatibility mode. Putting :encoding :default in your defsystem will achieve just that.
At the same time, if :encoding :default rather than :encoding :utf-8 were the default, then we'd gain nothing, and it would still be a horrible mess to ascertain which system has been compiled with which encoding.
It is not reasonable to expect users of ASDF to hack on external support code just to use non-UTF-8 external-formats, and the external library you plan for can never be complete because the external-format is user extensible.
Well, on the one hand, for portability's sake, one should probably one's lisp file to a universally supported external format. On the other hand, where portability is not a problem, one can either use :encoding :default and be back to the current semantics, or extend asdf-encodings as one extends external formats.
ASDF could easily be flexible regarding the external-format and not a limited bastion of portable open source code.
Agreed. Currently, ASDF is not flexible at all -- rather it is uncontrolled.
It would be very easy and workable to just name this :external-format, and to pass through encodings not recognised - all the quicklisp projects would work just fine using :utf-8 and other CL users could use encodings as needed.
Unhappily, passing through external formats is not portable, if only for CLISP. But if you're doing non-portable things, you can keep doing whatever you were previously doing with :encoding :default, or you can now define methods on asdf::component-external-format to do whatever you want, to override the default behavior of checking *encoding-external-format-hook*. Or then again, you can extend asdf-encodings to make it smarter.
In practice, how many people do you know who use a non-UTF-8 encoding, and how many of them will be majorly annoyed by having to either recode their source, explicitly specify their encoding, or add :encoding :default to preserve backwards compatibility?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "I've finally learned what `upward compatible' means. It means we get to keep all our old mistakes." — Dennie van Tassel