[R6RS] draft Unicode SRFI

[Marc Feeley]

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  
> conventions
> 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
>> called.
>>
>
> It sounds like `with-locale' belongs in a SRFI that better  
> standardizes
> 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.

> -Mathyew

Strangely you've become "Mathyew Platt" this morning...  Maybe you  
need to update the SRFI's authors list...

Marc