The advantage of port machinery is that you can specify a “timeout” for the operation and this can apply to all types of ports.
Since the SRFI 158 protocol does not specify how generators are created, there is no difficulty in a generator constructor that accepts a timeout argument such that if the underlying operation times out, an exception is raised.
That’s why I think ports are a more general mechanism,
Ports are indeed more general as Gambit implements them. However, SRFI 158 can be implemented portably, since generators and accumulators are just closures, whereas most Schemes do not provide hooks for adding new port types. While it is certainly not a requirement for R7RS-large SRFIs to have portable implementations, it is an advantage because it encourages adoption of them.
Why have two interfaces for the same concept?
In theory there is no need, but R7RS-large is meant to be practical; that means that complete consistency is not to be expected, since conceptual integrity is to be striven for rather than necessarily achieved in all details.
A SRFI providing versions of the five S-expression I/O procedures that accepted either ports or closures using SRFI 158 protocol would be a Very Good Thing.
As I haven't known Gambit's machinery until a few minutes ago, I
couldn't have proposed Gambit-style custom ports. :)
Unless by accident.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgSAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings "Ding dong, the
witch is dead." --Elliotte Rusty Harold on xml-dev