[R6RS] draft Unicode SRFI
Fri Jul 1 09:33:53 EDT 2005
On 1-Jul-05, at 9:16 AM, Mathyew Platt wrote:
>> Why do you define <eol> as either Unicode 10 or Unicode 12?
>> Only Unicode 10 (the #\newline character) should mark an end
>> of line.
>> Something is wrong with the \<eol><whitespace>* syntax because
>> <whitespace> is defined as "space, newline, tab, form feed,
>> vertical tab, and carriage return" in SRFI 14. Clearly newline
>> should be excluded.
> Thanks for bringing this up. I had forgotten that it's an issue.
> Here's my take:
> The wide definition of <eol> means that a file improperly
> transferred/opened on systems with different line-separator
> will still work.
I still disagree with you, because this is an end-of-line encoding
problem that this SRFI should not address. I think that, in the I/O
system, there should exist an end-of-line encoding setting that maps
CR+LF to #\newline, CR to #\newline, and LF to #\newline (in addition
to an end-of-line encoding that only maps LF to #\newline and an end-
of-line encoding that only maps CR to #\newline).
In any case, if you maintain your position you should change "Unicode
12" to "Unicode 13" (12 is form feed).
>> Why should a locale be specified with a string? Wouldn't a
>> symbol be more sensible? I have no experience with this, so
>> please correct me if I am wrong. A symbol also avoids the
>> need to create a copy of the string when current-locale is
> It sounds like `with-locale' belongs in a SRFI that better
> locales. Let's get rid of it and `current-locale'. I think the other
> `locale' functions are still useful with the default locale.
I agree. Perhaps you can move with-locale and current-locale to the
issues section and let people discuss this on the SRFI list.
Strangely you've become "Mathyew Platt" this morning... Maybe you
need to update the SRFI's authors list...
More information about the R6RS