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 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
not
have the desired effect of stimulating experimentation. My suggestion
would be
to provide some kind of graphical interface for defining process
networks
interactively.
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.
Larry
Something like Simulink for Matlab. Perhaps the work by
Hilderink and his colleagues on gCSP would provide a good starting
point.
Allan
--
Allan McInnes <amcinnes@xxxxxxxxxx>
PhD Candidate
Dept. of Electrical and Computer Engineering
Utah State University