[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: occam REPL
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
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?)
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
"incomplete process network" does not exist in occam, at least
separately-compiled hardware-based occam (where all globals are
explicitly, as in a .PGM file for the occam configurer).
Everything is a
self-sufficient black box that listens and talks. It exactly fits
Bereit's notion of a separate hardware node for everything.
If you make sure one box understands the output of another, or of
others (thus better than DOS/Unix pipes), then you can make a lot of
individual sane components, test each one individually, then hook
in complex topologies (using multiplexers and the like), and get
interesting results out. The ALT is your friend here; it allows
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
to provide some kind of graphical interface for defining process
OK, but you need direct access to the atoms, the way a REPL gives
you - then hook them together graphically if you please, but be
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>
Dept. of Electrical and Computer Engineering
Utah State University