Per Bothner scripsit:

> As a matter of style, I think this questionable - duplicating
> definitions from existing standards is a mistake.  (Where would
> you stop?  Duplicate the entire definition of <expression>?)

No, I'm referring to SRFI-109, and only the definitions of nested-comment,
intraline-whitespace, line-ending, letter, digit, and hex-digit that are
explicitly linked to R7RS.  That would add about nine lines to the SRFI,
but would eliminate the dependency on R7RS in the formal part.

> Is there any Scheme implementation where (eq? (make-string 0)
> (make-string 0)) returns #t?

Chez, Shoe, Oaklisp are the only ones I have right now that do so.
The last two probably don't matter in practice, but Chez is still an
important Scheme, even if it doesn't get as much publicity as the major
open-source varieties.

> I tweaked the draft to discuss this (theoretical) possibility:
>
>   Note that R6RS and R7RS allows eq? to return #t for distinct calls to
>   (make-string 0). A hypothetical implementation that does so needs
>   to initialize $<<$ and $>>$ some other way.

That's a first step, but not, I think, sufficient.

> SRFI-109 can't be implemented by a portable library anyway, so it
> seems fine to make such a requirement.   Given that it would be a
> really weird Scheme implementation where it is an issue.

SRFI 10[89] can't be implemented portably *today* for lack of a portable
readtable interface.  But definitions of $string$ and $construct$:* can
certainly be written portably modulo this one issue.  In order to make
them fully portable, the SRFI must say that the values of $<<$ and $>>$
are unique objects whose values are unspecified, and all definitions
of $string$ and of $construct$:* must be written so as to take this
into account.

--
John Cowan      xxxxxx@ccil.org         http://www.ccil.org/~cowan
Statistics don't help a great deal in making important decisions.
Most people have more than the average number of feet, but I'm not about
to start a company selling shoes in threes. --Ross Gardler