This note would require that all the procedures that accept strings also accept SRFI 135 texts, but would continue to return strings. This would provide symmetry with SRFI 135, where almost all the procedures accept either strings or texts ("textuals" in SRFI 135 jargon), but all the procedures except textual->string return texts. (The exceptions are text-ref and text-length, but textual-ref and textual-length subsume them.)

Currently any implementation could already do this, as domain extensions are in "is an error" territory. The implementation changes are trivial: make the procedures call textual->string on any string arguments. I'll have the sample implementation do this if (srfi 135) or (scheme text) is visible to cond-expand.

Arthur, what do you think? Too big a change? I don't think anyone is using SRFI 152 much yet, as it is almost subsumed by the widespread SRFI 13. As with other PFNs, we can make this optional-but-recommended and then vote on make it mandatory at the R7RS-large level.

Draft wording:

<b>Post-finalization note 1:</b> This note strongly encourages implementers of SRFI 152 who also provide SRFI 135 (as the R7RS-large Red Edition requires) to make all the procedures of this SRFI accept SRFI 135 texts as well as strings. The procedure <code>textual->string</code> is a straightforward technique and is used by the sample implementation. However, the procedures in this SRFI continue to return strings.

John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org
I am a member of a civilization. --David Brin