Last call Takashi Kato (30 Jun 2013 07:00 UTC)
Re: Last call Per Bothner (30 Jun 2013 07:46 UTC)
Re: Last call Takashi Kato (30 Jun 2013 08:35 UTC)
Re: Last call Per Bothner (30 Jun 2013 15:47 UTC)
Re: Last call Takashi Kato (30 Jun 2013 17:01 UTC)
Re: Last call Per Bothner (30 Jun 2013 17:19 UTC)
Re: Last call Takashi Kato (30 Jun 2013 17:47 UTC)
Re: Last call Per Bothner (30 Jun 2013 18:04 UTC)
Re: Last call Takashi Kato (30 Jun 2013 18:29 UTC)
Re: Last call Per Bothner (30 Jun 2013 23:11 UTC)
Re: Last call John Cowan (01 Jul 2013 20:01 UTC)
Re: Last call Shiro Kawai (30 Jun 2013 09:02 UTC)
Re: Last call Takashi Kato (30 Jun 2013 09:30 UTC)
Re: Last call Shiro Kawai (30 Jun 2013 09:54 UTC)
Re: Last call Takashi Kato (30 Jun 2013 10:27 UTC)
Re: Last call Shiro Kawai (30 Jun 2013 11:44 UTC)
Re: Last call Takashi Kato (30 Jun 2013 17:02 UTC)

Re: Last call Per Bothner 30 Jun 2013 15:47 UTC

On 06/30/2013 01:36 AM, Takashi Kato wrote:
> On 30/06/2013 09:45, Per Bothner wrote:
>> What is a binary input/output port?  There is no such thing in R7RS.

> The latest standard of Scheme (R6RS) defines what input/output port. (So
> far R7RS is yet draft state, I know it will be the latest standard
> sooner or later, but as long as standard defines it there is such thing
> in Scheme world.)

You're right - R6RS defines input/output port.  IMO That is a bug in
R6RS.  Consider the port-position function.  It represents "the position
at which the next byte would be read from or written to the port".
For an input/output port there are two positions - because there are
actually two separate ports.  Trying to mush them into into object
that "inherits" both sets of properties is bad design.  It's like
creating a data type that has the properties of both integers and lists.

>> I'm not talking ideal/clean design here.  The Java Socket class has
>> two separate methods: getInputStream and getOutputStream.
> I'm not sure how Kawa implements ports but if you have Scheme ports
> class/interface then can't it be like this?
>
> // InputOutputPort interface
> package org.scheme;
>
> // InputPort and OutputPort define read and write methods
> public interface InputOutputPort extends InputPort, OutputPort {
>
> }

One could so that, but that means causes compatibility problems with
the Java I/O classes.  InputStream/OutputStream/Reader/Writer are
all classes, not interfaces, so you can't multiply inherit them.

Obviously it is possible to implement InputOutputPort in Java,
as you show.  (I had to make some contortions to deal with binary
ports.)However, the concept is inherently bogus, so it would be
a mistake to do so.

If you want an object that bundles both an input port and an
output port, then use the socket directly.  That is what
C# does - it doesn't even let you (directly) get the two
streams, but you call Send/Receive directly on the Socket.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/