[asdf-devel] Update: encoding file options version.

[Douglas Crosher]

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