Re: occam REPL

[tjoccam@xxxxxxxxxxx]

> <SNIP>
> The process would start executing in parallel with the commandline and
> block when it reaches input.
> It could get a bit messy if the process starts outputting before reading
> but that could probably be solved
> somehow (another terminal?)
>
> Damian

Hi Damian,

This is what is nice about the slight extension to CSP/occam that I
devised. See my white paper in http://www.tjoccam.com documents. You
declare the channels (input OR output) in an OS-like layer OUTSIDE any
running code ("connectors", like wall sockets). You install your component
process by hooking it up to selected connectors. If there is no process
(yet) on the other end, it behaves exactly as if there were a blocking
process on the other end (output behaves this way too), and blocks. At
some later time you can hook up the communicating process, and after that
process reaches the point where it is ready for the communication, both
sides proceed.

I got this to work perfectly in DOS. It has to work, because it is the
behavior of a PAR, the second side of which is a SEQ whose components all
communicate with the first side. If you try to overlay it on "modern"
pipes and sockets (e.g. Linux), you may run into trouble, because they get
too smart and blow up instead of blocking. My trick here is to install a
third "doorstop" process that opens the pipe but never communicates on it.

Larry