Brian Mastenbrook scripsit: > * I don't think Small Scheme needs any definition of ports which is > more complex than that needed to read program text. Adding binary > ports adds too much in the way of assumptions about the environment in > which the small scheme implementation lives.
Note that I already have file-based binary I/O. Embedded systems, one of the use cases for small Scheme, often need to be able to push and pull bytes over the network. If binary I/O is in, custom binary I/O should be. > * I don't like the property list method you're using for custom port > objects. What is wrong with `port-set-read-procedure!', `port-set- > write-procedure!', etc.? How does naming some procedures with two > symbols instead of one help anything? It's a lot of procedures and it's not easily extensible, but I suppose I could stand it if group feeling (assuming anyone else is still listening!) runs that way. > * I don't like the assumption that ports are bivalent. This is a > complex thing to get right. One can take a file which is properly > encoded in UTF-8 and wind up introducing a decode error by mixing > binary and character operations on the same port. Bivalent ports can > be completely and usefully provided by a library on top of binary > ports if users desire them. Ports should not be both/and bivalent, merely either/or bivalent. I probably need a special posting on binary I/O altogether. > * I don't like the assumption that ports should naturally provide both > input and output. This isn't true in general. It's better to separate > out the types and have some way of creating an I/O port out of an > input port and an output port. On reflection I agree: make-input-custom-port and make-output-custom-port should be added and port? removed (it's trivial again). > * I don't like the inclusion of `read-line' and `newline' procedures. > Why is it useful to change the behavior of these procedures? This > seems like an opportunity for error. Good point. > * I don't like the hook for `read' and `write'. I don't even know why > it's there. If I'm going to replace it with something else, isn't that > something deserving of a different name? Yes, you're right about that too. After this evisceration, I'll post a second edition. -- Unless it was by accident that I had John Cowan offended someone, I never apologized. [email protected] --Quentin Crisp http://www.ccil.org/~cowan _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
