Email list hosting service & mailing list manager

The uses of custom ports John Cowan (22 Apr 2020 19:45 UTC)
Re: The uses of custom ports Marc Nieper-Wißkirchen (23 Apr 2020 13:07 UTC)
Re: The uses of custom ports John Cowan (23 Apr 2020 14:01 UTC)
Re: The uses of custom ports Marc Feeley (23 Apr 2020 14:25 UTC)
Re: The uses of custom ports Lassi Kortela (23 Apr 2020 14:31 UTC)
Re: The uses of custom ports Marc Feeley (23 Apr 2020 14:43 UTC)
Re: The uses of custom ports Marc Nieper-Wißkirchen (23 Apr 2020 14:35 UTC)
Re: The uses of custom ports John Cowan (23 Apr 2020 14:39 UTC)

Re: The uses of custom ports Marc Nieper-Wißkirchen 23 Apr 2020 13:07 UTC

Am Mi., 22. Apr. 2020 um 21:45 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> I believe that providing methods which are called when `read` and `write` (and presumably also `write-simple` , `write-shared`, and `display`) are applied to a custom port undermines most of the purpose of having custom ports.  The other operations on ports are comparatively trivial, and could be accomplished using generators and accumulators (of characters or bytes) either using an internal source or wrapped on top of non-custom ports (see <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/PortOperationsCowan.md> for some portable procedures to make the latter a bit easier).  Buffering and flushing would require extensions to the SRFI 158 protocol, but passing additional arguments to generators and accumulators could be used for that purpose (see <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/MoreGenerators.md> for an example).
>
> Scheme S-expression I/O, however, is more complicated, and as of right now it can *only* be done on top of a file port, string port, or whatever other kind of port the implementation might supply.  Custom ports provide the only extensibility for the existing substantial libraries for S-expression I/O.  If you don't want `read`, `write`, etc. to do S-expression I/O, you might as well write your own library rather than your own port implementation.

John, in case you are referring to the ideas I have been exchanging
with Shiro, there may be a fundamental misunderstanding (or I am
mistaking in this regard). I've never meant that `read' or `write' or
should be customizable for custom ports. Indeed, this would go against
the basic idea that's behind custom ports. My suggestion was just on
an implementation level. Never would a user see these methods.

Moreover, all custom ports in the sense of SRFI 181 would share the
same method in this implementation idea. This method would just be a
wrapper around a simpler `read' and `write' procedure, which
intercepts non-local control flow. In order to be able to rewind or
fast-forward the state, it will have to maintain and access some
buffer, which it can implement by using the internal primitives that
make up the custom port.

Marc