[asdf-devel] source file encoding

[Robert Goldman]

On 4/8/12 Apr 8 -7:37 PM, Faré wrote:
> On Sun, Apr 8, 2012 at 15:28, Nikodemus Siivola
> <nikodemus at random-state.net> wrote:
>> On 8 April 2012 17:36, Faré <fahree at gmail.com> wrote:
>>
>>> 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
>>
>> I disagree. Consider this:
>>
>> X has a system that used to be in, say, LATIN-9. He uses latin-9 at
>> home, and everything works fine. His users either use it as well, or
>> at least another single-byte encoding.
>>
>> ASDF is updated, and X's user reports breakage. Everything works fine
>> for X, because he didn't update ASDF yet. So he updates ASDF, and X
>> updates his system to specify :LATIN-9 (or :DEFAULT, or whatever).
>>
>> Now another of his users reports breakage, because /they/ didn't
>> update ASDF yet -- and their ASDF doesn't support :ENCODING, so things
>> break. They update ASDF, which in turn breaks another :LATIN-N system
>> they were using.
>>
>> The potential cost is non-trivial, and I really don't pretend to know
>> eg. how many Japanese hackers user non-UTF-encodings in their source.
>>
>> IMO encouraging people to add :encoding :utf-8 is much saner.
>>
> I agree that transition costs must be considered.

This is somewhat OT, since it's really about general transition costs,
but should we add a continuable error to parse-defsystem for handling
unrecognized options?

I like beating people over the head that this might not do what they
want, but I don't like leaving them with no way to proceed.

Possibly even better to have a continuable error that /remembers/ a
defsystem option as something to be ignored.  Then we wouldn't /keep/
complaining about :encoding over and over --- one continuable error
continue and you'd be done.

cheers,
r