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:
http://www.cs.brown.edu/publications/techreports/reports/CS-03-20.htmlAt 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... :-)
-Marc On Aug 19, 2006, at 7:19 AM, Damian Dimmich wrote:
Hello,While I think that a graphical system for testing POP style sections of programs would be reallycool, 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:pseudocode: 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 solvedsomehow (another terminal?) Damian 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 on-the-fly, 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 leastseparately-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 MarkBereit's notion of a separate hardware node for everything.If you make sure one box understands the output of another, or of severalothers (thus better than DOS/Unix pipes), then you can make a lot ofindividual 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 infrequentparameter changes or resets controlled on another channel.Not impossible, but potentially difficult enough that it would nothave the desired effect of stimulating experimentation. My suggestionwould beto provide some kind of graphical interface for defining processnetworksinteractively.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 todesign sane startup and shutdown (or reset). I find pencil and paper better for that. LarrySomething like Simulink for Matlab. Perhaps the work by Hilderink and his colleagues on gCSP would provide a good startingpoint.Allan -- Allan McInnes <amcinnes@xxxxxxxxxx> PhD Candidate Dept. of Electrical and Computer Engineering Utah State University