[R6RS] I/O

[dyb at cs.indiana.edu]

> One issue which the Port I/O SRFI raises, which also affects the 
> core/library split, is the fate of R5RS procedures which support a 
> "current port".  The Port I/O SRFI redefines some of these procedures to 
> require a port argument, e.g. read-char, peek-char, and write-char.

Please forgive me if I've forgotten something important about port SRFI or
an earlier discussion, but why are these now going to required a port
argument?  What's wrong with including a curren port and allowing the port
argument to be optional?  It's a nice convenience and also helps when
teaching the language.

Kent