[R6RS] R6RS Unicode SRFI controversial issues

[Anton van Straaten]

I'm in full agreement with all of Kent's points below.

In particular, support for newlines in strings, without a preceding 
backslash, is very useful for embedding code in other languages (SQL, 
Javascript, etc.)

I notice that Bigloo, Chez, Gambit, Guile, MIT, PLT, Scheme 48, SCM and 
SISC all support this now:

"Multi-line strings
are common
practice"
=> "Multi-line strings\nare common\npractice"

If a programmer finds either approach easier to read, they're free to 
choose that approach, i.e. it's a stylistic choice for the programmer. 
That's preferable to having the standard impose a single solution for 
all cases, since each is appropriate in different circumstances.

BTW, if Scheme supported something like a "here document", as in sh, 
bash or perl (http://www.faqs.org/docs/abs/HTML/here-docs.html), then 
ordinary strings could be more constrained.  I'm guessing we don't want 
to go that far at this point, though.

The rest of the proposal is fine with me.

Anton


dyb at cs.indiana.edu wrote:
>>...  Note that if we specify that  
>>whitespace is ignored after \<newline>, we probably have to adopt the  
>>\<space> escape (which would expand to a single space character) so  
>>that the continuation line can start with a space, ...
> 
> 
> I agree that we should allow the \<space> escape, especially for cases
> like this:
> 
>     (display "That is, I prefer:\n\
>              \   spaces at the beginning of the line when\n\
>              \   that's where they are supposed to end up\n")
> 
> to
> 
>     (display "That is, I prefer:\n   \
>               spaces at the beginning of the line when\n   \
>               that's where they are supposed to end up.\n")
> 
> 
>>>  I'd prefer that we not disallow newlines in
>>>strings, but don't feel strongly about it.
>>>
>>
>>I'm OK with that.  However, newlines are not allowed in C strings,  
>>and the obligation to break strings on multiple lines with \<newline>  
>>makes multiline strings somewhat easier to parse for humans (i.e. you  
>>have a visual clue at the end of the lines that this text is in a  
>>multiline string).
> 
> 
> C doesn't support some of the other things you've proposed, either.
> In any case, ...
> 
> (display "\
> If I've got some text to print out,\
> I'd prefer not to have slashes at the end\
> of each line.  They get in the way visually\
> and are a nuisance if I need to reformat\
> the text.\
> ")
> 
> 
>>Octal is dead.  ...
> 
> 
> I'm fine leaving the \o syntax out.
> 
> 
>>>I would like for all characters to be followd by a delimiter, so that,
>>>for example, #\s3 is an error.  Requiring all characters to be  
>>>delimited
>>>also helps leave open future extensions.
>>>
>>
>>Fine by me.  Do you also mean that #\(foo and #\ foo are errors?   
>>That too is fine by me.
> 
> 
> Yes.  It seems less confusing to require all characters to be delimited.
> 
> Kent
> _______________________________________________
> R6RS mailing list
> R6RS at iro.umontreal.ca
> http://mailman.iro.umontreal.ca/mailman/listinfo/r6rs