Opened 7 years ago

Closed 7 years ago

#31 closed defect (wontfix)

custom ports

Reported by: alexshinn Owned by: alexshinn
Priority: major Milestone:
Component: WG1 - I/O Keywords:


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

Change History (3)

comment:1 Changed 7 years ago by cowan

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.

comment:2 Changed 7 years ago by kumoyuki

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.

comment:3 Changed 7 years ago by cowan

  • Resolution set to wontfix
  • Status changed from new to closed

WG1 voted not to have custom ports.

Note: See TracTickets for help on using tickets.