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 <[email protected]> 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 _______________________________________________ asdf-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
