TCP library

[Pascal Serrarens]

Richard A. O'Keefe wrote:
> 
> Martin Wierich <martinw@cs.kun.nl> wrote:
>         Our approach differs from the Unicon approach,
>         because we give our channels types.
> 
>         The type constructor for channels has as its argument
>         the type of the messages being sent/received.
> 
> Yes yes that's fine and it's a wonderful thing to have.
> 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.

Yes, that may be very useful to do

(note: I work together with Martin (read: I fight with Martin
 about...) on the communication libraries, he's doing the
Clean implementation, I'm doing the Concurrent Clean impl.)

For example, we could have new modes for fopen:

//	File modes synonyms

FReadText	:== 0	//	Read from a text file
FWriteText	:== 1	//	Write to a text file
FAppendText	:== 2	//	Append to an existing text file
FReadData	:== 3	//	Read from a data file
FWriteData	:== 4	//	Write to a data file
FAppendData	:== 5	//	Append to an existing data file
FReadTCP    :== 6	//	NEW!
FWriteTCP	:== 7	//	NEW!

fopen		:: !{#Char} !Int !*Files -> (!(!Bool,!*File),!*Files)

Now you can use TCP communication like it were a file.
We could also overload the existng fread? functions so that
they work with TCP (and other) channels.

Implementing this is (almost) trivial.

> Conversely, if you have typed send/receive channels,
> why not typed write/read connections to disc files?

We will, using dynamic typing.

But for files it is often useful to read/write mixed types:
- read the length of the file -> int
- read the name of the file -> string
- read the status of the file -> bool
etc.

If we would force the file to be of type {#String} for example,
we could only read character strings and we would have to
convert them all the type.

On the other hand, the same is true for TCP/IP communication
-> another pro for providing the file-like interface.

Thanks,
   Pascal Serrarens.