On 04/23/2012 01:36 AM, Faré wrote:
On Sun, Apr 22, 2012 at 08:48, Pascal Costanza pc@p-cos.net 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