Michael Sperber scripsit:
> [I don't speak for the editors.]
>
> Your wording makes me suspect there's a misunderstanding.
Probably quite a few. I unfortunately intertwingled several things
here. Let me try to sort out the editorial, the syntactic, and the
functional-extension issues.
A) The functional extensions are most easily expressed:
1) A codec that specifies the local default encoding.
2) An eol-style that means "accept any known EOL style on input, use the
native eol-style on output". This behavior is more useful than accepting
only the native eol-style on input, because it's no longer reasonable
to expect that all accessible text streams use the native encoding.
I think these should be simple and uncontroversial.
B) There is the question of what "make-transcoder" accepts. The
specification says that the first argument is a codec (of unspecified
type) and the second two arguments are symbols.
However, the intent is clearly to allow the second and third arguments
to be expressed using the "eol-style" and "error-handling-mode" macros,
and these macros are required to return symbols *only* if their argument
is one of the standardized names, as a result of the sentences "If *name*
is not one of these identifiers, the {effect of evaluating this, result
[of] the} expression is implementation- dependent. (I presume the
discrepancy in language is accidental.)
This needs editorial disentangling. Either eol-style and
error-handling-mode should be disposed of in favor of just symbols, or
"make-transcoding" should be explicitly allowed to accept non-symbols.
C) You argue that it's useful to be able to represent codecs as procedures
so that there need be no central registry known to "make-transcoder".
However, since this is not standardized, there is no portable
way to write a codec, and a library containing one is inherently
implementation-dependent. Thus an implementation might require one to
write (make-transcoder foo), (make-transcoder 'foo), or (make-transcoder
(foo)).
In any case, an implementation can easily permit codec-procedures to
appear in libraries, accompanied by a "register-codec!" procedure that
associates the procedure with a symbol for use in user code.
And if it's useful for codecs to be procedures, such that it's worth
leaving the type unspecified, why isn't that equally suitable for EOL
styles and error-handling modes? Why nail down that the standardized
cases are represented by symbols, when all is left open for codecs?
D) It's not obvious why one must invoke a procedure to fetch the
standard codecs, since what is returned is immutable. Why not just bind
the names directly to the codec objects?
--
BALIN FUNDINUL UZBAD KHAZADDUMU cowan_at_ccil.org
BALIN SON OF FUNDIN LORD OF KHAZAD-DUM http://www.ccil.org/~cowan
Received on Fri Nov 10 2006 - 14:46:06 UTC