On 04/23/2012 01:36 AM, Faré wrote: > On Sun, Apr 22, 2012 at 08:48, Pascal Costanza <[email protected]> wrote: >> >> On 22 Apr 2012, at 00:01, Faré wrote: >> >>> I'd like to add :encoding now, if only because >>> if we are to ever use it, we must wait for it to be >>> in an asdf that has already made its way to all/most implementations >>> before it's considered universal enough for libraries to rely on it. >>> Whereas if we don't end up using it, it's easier to remove later. >>> >>> But you're right: I should not actively encourage its use for now, >>> except for people who know what they are doing and are ready to deal >>> with stricter dependencies and possible future change. >> >> These two paragraphs show very clearly what's wrong with ASDF (since v2.x): >> Experimental features are pushed to CL implementations (that mostly pick it >> up because ASDF has turned into a de-facto standard), instead of figuring >> out a way that helps the CL community to participate in having a say on what >> the best solutions for particular problems could be. The decision which >> concrete experimental feature is put into ASDF is largely in the hand of the >> maintainers. >> >> People who know what they are doing can _always_ go to some place and fetch >> the concrete experimental feature that they need. Those people _don't need_ >> a feature to be available in all CL implementations. The only features that >> should be in all CL implementations are the ones that are stable and mature! >> > Unlike the support for multiple encodings and their detection, that is > indeed experimental and included in the extension system asdf-encodings, > the hooks and defaults for encodings in ASDF are indeed mature and stable. > They add all of 68 lines to ASDF out of a current count of 4422 > (versus 2011 before I took over), of which explicit :encoding > vs implicit auto-detection only add about 20 lines. > I don't think it's an excessive price.
My main concern was the liability, but after developing support tools further it no longer seems such a big deal having the :encoding declaration released now. I thought the tools would need to update the :encoding declarations in the .asd files which would be very difficult, but the simple solution is to just remove them when doing any recoding. Quicklisp could remove all the :encoding declarations from releases as the coding file options are updated or inserted, or perhaps do some consistency checking between the file encoding and the declared :encoding after loading systems. I do think the :encoding declaration is unnecessary, but tools can deal with it easily. The only issue may be an author using the :encoding declaration to read octets from an encoded file as ISO-8859-1 characters - but who would do that! Regards Douglas Crosher _______________________________________________ asdf-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
