> Alex Shinn wrote:
>> (display (string "list: " ls #\newline) to-what-ever-port-you-like)
>
> 1) Does string use display or write to convert objects?  You often need
>  to interleave both.

- effectively elements composing lists and vectors assume write formatting,
  otherwise display formatting is assumed; which seems fairly standard.

> 2) This can be inefficient to the point of being unusable.  If ls takes
>  up more than 50% of your memory, you can't even build the
>  intermediate string.

- agreed; who says strings can't actually passed as lazy buffered streams?

>> (Personally I see no reason not to consider advocating simply backward
>>  compatibly extending (string ...) rather than advocating "standardization"
>>  of a function with limited additional utility which is arguably
>>  inconsistent with the language's philosophy; but that of course is the
>>  benefit that the SRFI process/forum provides us all.)
>
> I wasn't suggesting this for backwards compatibility so much as forwards
> compatibility.  There is currently some uncertainty in the Scheme
> community as to exactly what a character is.  For porting Unicode-aware
> Gauche scripts to other Schemes I've been toying with the idea of
> unifying characters and numbers.  For future Schemes I wonder if
> implementing characters as single-character symbols might not be a good
> idea (probably still implemented using tagging under the hood rather
> than bloat the symbol table).
>
> Also I think it's good to keep string in the same style as list and
> vector - it should build a sequence from the individual elements, and
> not extrapolate them.

- suspect it all largely depends on what one is attempting to optimize for.

> --
> Alex
>