Ticket #30 (writing defect)
string ports
| Reported by: | alexshinn | Owned by: | alexshinn |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | WG1 - I/O | Keywords: | |
| Cc: |
Description
Do we support SRFI-6 string ports, reaffirmed by R6RS?
Do we support the with- and call-with- utilities?
Change History
comment:2 Changed 19 months ago by cowan
- Status changed from new to closed
- Resolution set to fixed
The WG voted to accept SRFI-6 string ports as part of the core.
comment:3 Changed 16 months ago by alexshinn
- Status changed from closed to reopened
- Resolution fixed deleted
Note: See
TracTickets for help on using
tickets.
"Reaffirmed" is a little misleading. SRFI 6 ports are created by OPEN-INPUT-STRING and OPEN-OUTPUT-STRING, and GET-OUTPUT-STRING extracts the text accumulated in an output port as a string. In R6RS, we have OPEN-STRING-INPUT-PORT and OPEN-STRING-OUTPUT-PORT, where the latter returns both the port and the anonymous extractor.
SRFI 6 is supported (according to the documentation) by PLT, Gauche, MIT, Gambit, Chicken, Bigloo, Scheme48/scsh, Guile, Kawa, SISC, STklos, RScheme, s7, SXM, Pocket, stk, and Sizzle, plus the R6RS implementations IronScheme?, Ikarus, Larceny, and Mosh. Only SCM, SigScheme?, and Scheme 9, plus the R6RS implementation Ypsilon, lack support for it.
Neither interface seems to me superior to the other, but I recommend we go with SRFI-6 because of its near-ubiquity.