On Thu, Apr 12, 2012 at 04:51, Douglas Crosher <dtc-asdf@scieneer.com> wrote:
If you accept that library authors will choose their encoding, even for the system definition files, then the only solution seems to be to add an encoding option to 'find-system and suggest this be used to load the system definition.
Unhappily, things like :depends-on (:this-system) cannot be all updated by users to specify a correct encoding, even less so when said encoding can change. Therefore it is a bad idea to have user-specified encodings for system files, unlike system-specified encodings for source files, since the system is maintained by the same people as part of the same project. The principle behind ASDF 2 has always been: those who know and those who specify should be the same person. So far, asdf 2.20.13 doesn't specify an encoding for asd files, so it's always :default, which in practice means that it's not portable to use non-ASCII in component names or file names. So far, that's what common practice is, and the diversity of filesystems makes it not portable to use anything but a subset of ASCII for filenames, anyway. I'm tempted to enforce a non-configurable UTF-8 for .asd files, too, so that it becomes possible to name components beyond ASCII, and that if and when filesystems become more standardized or some user is daring, ASDF is already ready to take advantage of that. That's a mostly independent change though, and my current take is to see with ASDF 2.21 how this change goes, and if it's successful, push for UTF-8 in system files in 2.22 -- and if it's a disaster, back out and issue a 2.22 immediately with :default as default. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is not recognized in the full amplitude of the word that all freedom is essentially self-liberation — that I can have only so much freedom as I procure for myself by my ownness. — Max Stirner