This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 31: custom ports

2011-01-24 06:58:19
WG1 - I/O
2010-02-23 17:04:36

Do we provide a mechanism for custom ports, on which for instance string ports could be created?

I wrestled with these a lot, but couldn't find anything satisfying. If you treat a custom port as an object on which you can get/set procedures to do the work, you wind up with a getter/setter for every I/O procedure you have. And you need to say what happens if the user provides only some of them. It's a big mess. You can make the procedures generic and use a symbol to indicate which property is being get/set, but all that does is clean up the page some, the implementation is still messy. Having multiple kinds of ports (binary/textual, string/file, input/output) just makes the mess worse.

I am opposed to standardization here, and I think the R6RS effort was premature.


I am pretty conflicted over this issue as well, as Oleg Kiselyov & I (and a few others) tried to work up an I/O SRFI many moons ago. Things got very complex, very quickly.

Arguably, all I/O should be moved out of the core language specification. C managed to get along with only "library" compliance in I/O for many long years. Additionally, I/O is the canonical example of where side-effects are unavoidable. Nevertheless, Scheme without a free system for reading s-expressions wouldn't feel like much of a lisp either, and the utility of the language would be significantly degraded.

The I/O library needs significant work, and I am more than half inclined to say it should be a WG2 job, except for the Lisp-y-ness issue.


WG1 voted not to have custom ports.