TCP library

[Martin Wierich]

Hi there,

Pascal wrote:

>(note: I work together with Martin (read: I fight with Martin
> about...)

We love it, don't we ?

Richard A. O'Keefe wrote:
> BUT
> you have missed my point, which is that for a lot of
> applications it is *USEFUL* to have TCP channels that
> are just like files, because the protocol the *OTHER*
> end of the communication speaks is a *TEXT* protocol.

Enabling the fread/fwrite functions and others defined in StdFile to
operate on TCP connections is a good idea.

But the StdFile's collection of functions is not enough. Sending and
receiving data via a network can block the whole Clean program (I make a
distinction between "Clean" and "Concurrent Clean"). Blocking makes File IO
and network IO so different, and this has implications for a lazy
functional language. Imagine a client program, that sends data to a server,
which will send it back on another channel. Finally the client receives
that data again. When we write

  # channel1               = fwrites "hallo wereld\n" channel1
    (halloWereld,channel2) = freadline channel2
  = (halloWereld,channel2,channel1)

,the order of evaluation is not specified. In this example the Clean
compiler would choose for evaluating freadline before fwrites, and the
program would block forever, because it's never sending anything. There a
two ways to go around this. One way is to use strictness, e.g.:

  # channel1               = fwrites "hallo wereld\n" channel1
    (halloWereld,channel2) = freadline channel2
    (channel1,channel2)    = doSeq channel1 channel2
  = (halloWereld,channel2,channel1)
  where
    doSeq :: !.x .y -> (!.x,.y)
    doSeq x y = (x,y)

But I don't like that ! It is not nice !

The other way is provided by the send/receive functions

  # (channel1,world)             = send channel1 "hallo wereld\n" world
    (halloWereld,channel2,world) = receive channel2 world
  = (halloWereld,channel2,channel1,world)

I conclude:
1.  I vote for an extension of the StdFile module to deal with network
connections (TCP and (later) pipes). In many cases blocking does not
matter, and with Concurrent Clean (not Clean) this doesn't matter anyway.
2.  There is also a need for the mentioned send/receive functions, so that
one can nicely specify sequentialisation. These functions have another
signature than the fread/fwrite functions. The send/receive functions could
probably operate on the same set of objects than the fread/fwrite functions
(including "ordinary" files and stdio)

regards
  Martin Wierich