[I don't speak for the editors.]
Your wording makes me suspect there's a misunderstanding.
John Cowan <cowan_at_ccil.org> writes:
> 2) The second argument specifies the EOL style. It is either:
>
> a) one of the symbols 'cr, 'lf, 'crlf, or 'ls; or
>
> b) an OUT returned by the standard macro eol-style when passed
> an identifier other than one of those four; or
a) and b) are the same. The description of `eol-style' says: "the
form evaluates to the corresponding symbol." (I don't know how to say
it clearer.)
> a) one of the symbols 'ignore, 'raise, or 'replace; or
>
> b) an OUT returned by the standard macro error-handling-mode
> when passed an identifier other than one of those three; or
Same here.
> 1) If the first argument is 'latin-1 or 'utf-8 or 'utf-16 or 'local, the
> transcoder will use the specified character sets. If it is a different
> symbol, the meaning is implementation-defined.
The reason why the encoding is not symbol is so it can be an object
specifying an encoding and decoding algorithm, say via code. (The
reference implemenetation of SRFI 81 works that way.) This way, you
can add new encodings at a later time, in separate libraries. If it's
a symbol, `make-transcoder' must have centralized and global knowledge
over all the encodings in use. This would be non-modular and hard to
extend.
> 2) If the first argument is 'cr or 'lf or 'crlf or 'universal, the
> transcoder will use the specified EOL style, where 'universal means
> "accept any EOL style on input, produce the local EOL style on output".
> (For reference, the known EOL styles are CR, CR+LF, LF, NEL, CR+NEL, and
> LS, where NEL = U+0085 and LS = U+2028.) If it is a different symbol,
> the meaning is implementation-defined.
What happens on output?
> 3) If the third argument is 'ignore or 'raise or 'replace, then the
> transcoder will take the appropriate action on encoding errors. If it
> is a different symbol, the meaning is implementation-defined.
That's almost exactly the meaning of the current specification. The
only difference is that you're constraining the implementation-defined
argument to be a symbol. This would restrict the usefulness of the
possibility of an implementation-defined extension. For example, it
would make it difficult to specify an error-handling mode that
corresponds to `replace' with a user-specified character.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Thu Nov 09 2006 - 07:04:17 UTC