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

Re: occam REPL

On the running of incomplete process networks, this is possible under JCSP and the .NET library using the Process Manager class. This was something I was considering more as a teaching and learning tool. For example, give a student a small REPL script that leaves them with an input channel and an output channel. Their task is then to modify the input in a certain manner and then send it down the output (most likely to a printing process), thereby learning process by process. I can also see however that Larry's idea is a very good one, although I always view components as having properties associated with them as well as channels (events). Maybe you do discuss this in your white paper, unfortunately I haven't the time to read it at present (its that time of year when us Research Students have to justify our existence).
One of the main reason's I like .NET (read C#) is that it is slightly more component based than Java. There are proper property abstractions, and setting events is a little more sensible (though still not ideal), there being no action listeners. My main hangup is creating your own "component" within the framework, and is basically a simplified version of OO's observer pattern.
That said, I'm not against OO. It has some advantages that can prove useful, if you know how to use them sensibly and safely. However, when I think in OO, I see encapsulated data, not actively running and interacting components. Thats where more sensible approaches, such as occam, etc, come into play. 

Kevin Chalmers
Research Student
Napier University.

tjoccam@xxxxxxxxxxx wrote:

Hi Kevin, Matt, Allan and all,

Kevin wrote:

All the channels are hidden inside the Plug and Play components.  This
also scales up for processes with multiple inputs and outputs:
<SNIP>
As I said, its more of a toy than anything, but it can be a little bit fun
just plugging components together like this.


It can be more important than that, if it leads to a sane and usable
definition of "component".

Matt wrote:

I certainly do appreciate the attractiveness of a REPL; I spend a great
deal of my time developing in Scheme, and greatly value the
interactivity a REPL affords. However, a REPL does present a number of
thought problems for a CSP-based langauge. For example, any attempt to
develop a REPL would require us to be able to execute incomplete process
networks, so you could develop and execute individual processes one at a
time.


Again, this sounds like sane components (by which I mean things like a
component you can install under the hood of your car, as opposed to OO
"components"; see my web page www.tjoccam.com and white paper). They would
be like black boxes with channels hanging out, and the REPL would
presumably involve two stylized text channels with an ALT functioning as
the OS. Does anyone have the official, agreed-upon specs for the behavior
of a REPL? Just turn it into an occam harness, in which the incomplete
process network can be inserted. I'd consider working on it myself...


<SNIP>
It may be of interest to this list that the Transterpreter has now gone
open source, and an anonymous SVN now exists[1].


The REPL would complement this beautifully, by giving everyone an easy
introduction to sane components.

Larry Dickson




This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.