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

RE: occam REPL

If our goal is to get the world to try CPA / POP, it's a good idea to
give them something fun to play with.

The majority of today's programmers use cool IDE's which offer syntax
support and component awareness. 

So why not build an occam process diagramming tool that works in such an

Occam has an advantage here. Implicit in the occam approach is the
drawing of simple process diagrams, as in the Inmos occam tutorial. It
would be a 'relatively easy' matter to create a graphical tool for these
circles (processes) and lines (channels), which then generate executable
code in occam-pi JCSP .Net, etc. You could add channel type definitions
to the connecting lines, and double-click the process circles to wire up
the next level of processes/channels within.

Such a tool could be integrated into a popular programming IDE's such as
Visual Studio .NET etc, which would encourage thinking about
mixed-language projects where occam has an important place.

The nice thing is the close correspondence between these process
diagrams and occam code, whereas OO trace and relationship diagrams
(static and dynamic views of objects) are much more abstract. I found it
much harder to draw OO diagrams and generate code from them. Frequently
the OO code was refactored to express a different OO implementation, but
the diagram didn't get updated. With an occam diagramming tool, however,
you could edit the occam code and the diagram would regenerate

Does anyone know the name of the occam process diagrams?


-----Original Message-----
From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On
Behalf Of Damian Dimmich
Sent: Saturday, 19 August 2006 8:50 PM
To: occam-com@xxxxxxxxxx
Subject: 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

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
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 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.
> "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
> 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
> others (thus better than DOS/Unix pipes), then you can make a lot of
> individual sane components, test each one individually, then hook them
> 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
>> 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
> you - then hook them together graphically if you please, but be ready
> 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