Will Clinger wrote:
> the name of the library were (srfi 152), not (srfi-152).
EWONTFIX.
> it exported the 32 procedures that are also exported by
> (scheme base). Why shouldn't a program that imports
> (rnrs base) instead of (scheme base) be allowed to use this
> library without having to import (scheme base) and resolve
> any extraneous conflicts that might result?
They are commented out, and an implementation can restore
them if it wants.
> The string-span and string-break procedures are not specified by
> SRFI 13, but their descriptions in the SRFI document do not note
> that fact.
Fixed.
In srfi-152.sld, the definitions of
string->utf16be
string-utf16le
utf16be->string
utf16le->string
aren't right. The first two ignore their one argument, and none
of the four accept the optional arguments specified by SRFI 152.
First two definitions fixed. Optional arguments removed from
SRFI 152, where they did not belong, as these are strictly R6RS-style
procedures.
Per Bothner writes:
[140 and 152] seem to be mostly "compatible", except of course for the biggie:
where a srfi-140 procedure returns an immutable string,
srfi-152 returns a mutable string. But I believe those strings
will be equal?, so in general code written for one will work
with the other.
Agreed.
Which is why I don't intend to implement srfi-152 for Kawa, at least not in any
default modes, including (import (kawa base)). I am even more convinced that
having both srfi-135 and srfi-152 in the core of the same programming language
will lead to a confusing mess.
Well, I don't agree, but we'll see what the voters think of SRFI 152.
--
If I have seen farther than others, it’s because my head is sitting
on the shoulders of a giant. --Trond Engen