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

Re: occam REPL


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