On Tue, Apr 17, 2012 at 10:32, Douglas Crosher dtc-asdf@scieneer.com wrote:
The :encoding support is a dead end and I suggest it be removed now and not be put forward to the wider community. The documentation encouraging the use of the :encoding option is not constructive. People would be poorly advised to use the :encoding option in preference to an encoding file option.
I'm not sure why you say it's a dead-end. It certainly costs very little in terms of lines of code, and guarantees a deterministic behavior without the costs of detection. It's cheaper to put say :encoding :koi8-r in your defsystem than -*- coding: koi8-r -*- in each and every file (assuming each of the contributors' editor is otherwise configured to accept koi8-r for those files).
Until we're ready to merge ~500 lines of code into ASDF itself (which is not a light thing, and supposes the design is stable and widely accepted), I believe this is a good intermediate solution, where the provided extensibility hooks allow everyone to have his way.
The latest documentation additions:
"We invite you to embrace UTF-8 as the encoding for non-ASCII characters starting today, even without any explicit specification in your .asd files. Indeed, on some implementations and configurations, UTF-8 is already the :default, and loading your code may cause errors if it is encoded in anything but UTF-8. Therefore, even with the legacy behaviour, non-UTF-8 is guaranteed to break for some users, whereas UTF-8 is pretty much guaranteed not to break anywhere, although it might be read incorrectly on some implementations. In the future, we intend to make @code{:utf-8} the default, to be enforced everywhere, so at least the code is guaranteed to be read correctly everywhere it can be."
People would be poorly advised to use any encoding without regard for the locale. Even UTF-8 is not guaranteed to 'not break anywhere' - just try running SBCL in an ISO-8859-1 locale and loading UTF-8! There is no need to make :utf-8 the default or to enforce it and this is not an appropriate path.
I disagree, all 8-bit locales will read utf-8 without *breaking*, though displaying funny characters. A utf-8 locale will *break* when reading arbitrary 8-bit files. That's a big difference. As for multibyte CJK locales, yes they may break when fed utf-8 code, but implementations that support them also support unicode, and whoever uses these locales is already having configuration issues that the current asdf proposal will make better, not worse. Therefore, when publishing a library online, your best bet is to use UTF-8. That's not just my personal opinion. That's what the authors of the ~100 libraries that use non-ASCII out of the ~700 in Quicklisp have chosen. If "we" are to formally standardize on anything it should be on this de facto standard.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A fruitful discussion is a negotiation, out of which emerges meaning. Classic works are standards, and politeness is a protocol, to ease such negotiation. With a reasonably expressive language, neither is strictly needed, but both sure do help, and they are where the general progress happens.