John Cowan <cowan_at_ccil.org> writes:
> A) The functional extensions are most easily expressed:
>
> 1) A codec that specifies the local default encoding.
Does this always exist? What is it, say, for Windows?
> 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 get your point. Thanks for explaining.
> (I presume the discrepancy in language is accidental.)
Yes, at least so far as I know. I'll try to fix it.
> 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.
That is true, but it is possible to imagine that one will be added in
the future, or specified as a SRFI. Alternatively, SRFIs or a future
standard may specify additional codecs. In either case, an
implementation might not be portable, but implementations for
different Scheme systems might provide a consistent interface.
> 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.
That would be unmodular, as it would make codecs depend on state;
interference would be possible and, ultimately, likely.
> 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?
Good point. My subjective take is that we figured error-handling
modes and EOL styles are easy to enumerate, while codecs are not.
> 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?
That issue came up in the discussion among the editors. The thread is
here:
http://www.r6rs.org/r6rs-editors/2006-July/001533.html
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Sat Nov 18 2006 - 10:28:31 UTC