Re: occam REPL

[tjoccam@xxxxxxxxxxx]

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