[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: occam REPL

Hi everyone,

I've been following this most recent thread regarding a REPL for occam, and Damian's last post triggered me to recall that there *is* an experimental language within DrScheme that is an implementation of Functional Reactive Programming. The language is FrTime (pronounced "Father Time"), and I saw a demo of it a couple of years ago. The demo showed off features that would appear to be desirable for an occam REPL as this thread has discussed. Check out this URL for an abstract and link to a paper:


At the very least, this experimental language is one possible model of how to build a REPL for occam.

Regarding Damian's question about foo's output starting before it attempts to input, here are some thoughts:

I'm going to speak in terms of a DrScheme's REPL environment, which includes an interactions pane. Input and output within the interactions pane could be considered implicit, external, pre-defined channels. Therefore, the interactions pane is a process that is blocked, waiting for each user input. Examples of inputs include defining channels, defining processes, starting processes, writing to or reading from the predefined channels, etc. Damian's question assumes that outputs don't block, but this doesn't have to be the case. Since output is now a channel, it could block until the user explicitly reads from the interaction process's output channel. In this way, foo can't start outputting until the user attempts to read.

Einstein famously said: "The environment is everything that isn't me." This is a process-centric philosophy, and view of the universe! :-) But in the REPL, the *user* gets to play the role of the environment, by offering opportunities for processes to engage in observable events, i.e., inputs and outputs... :-)


On Aug 19, 2006, at 7:19 AM, Damian Dimmich wrote:


While I think that a graphical system for testing POP style sections of programs would be really
cool, I do think it could be done from the commandline.

It would be possible to start processes up individually and get them going as you hook them together. A good way to test them would be to have the ability to send data down an 'unhooked' channel end and view the result at the other end. So REPL-style you could do something like:
define channel x:
define channel y:
start proc foo with x in, y out.
x ! 3
-> output from foo here.

proc foo could have been loaded from a file previously with a 'use' or 'include' at the commandline.

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?)

tjoccam@xxxxxxxxxxx wrote:
I'm not entirely convinced that a REPL-style interface
would be the best way to
get people playing with process-oriented programming
(which seems to be your goal).
Wiring up incomplete process networks, and adding to them
seems to me like something that would be difficult to achieve
via a textual interface.

That is where I think you may have been misled by standard paradigms. An
"incomplete process network" does not exist in occam, at least
separately-compiled hardware-based occam (where all globals are defined explicitly, as in a .PGM file for the occam configurer). Everything is a self-sufficient black box that listens and talks. It exactly fits Mark
Bereit's notion of a separate hardware node for everything.

If you make sure one box understands the output of another, or of several
others (thus better than DOS/Unix pipes), then you can make a lot of
individual sane components, test each one individually, then hook them up in complex topologies (using multiplexers and the like), and get rather interesting results out. The ALT is your friend here; it allows infrequent
parameter changes or resets controlled on another channel.

Not impossible, but potentially difficult enough that it would
have the desired effect of stimulating experimentation. My suggestion

would be

to provide some kind of graphical interface for defining process



OK, but you need direct access to the atoms, the way a REPL gives it to you - then hook them together graphically if you please, but be ready to
design sane startup and shutdown (or reset). I find pencil and paper
better for that.


Something like Simulink for Matlab. Perhaps the work by
Hilderink and his colleagues on gCSP would provide a good starting


Allan McInnes <amcinnes@xxxxxxxxxx>
PhD Candidate
Dept. of Electrical and Computer Engineering
Utah State University