I'm not sure if anyone would be interested, but we've recently developed a .NET library based on JCSP. The pertanance to this is that there is a Python based REPL for .NET out there (Iron Python) and I have done some playing about with it. Specifically, we designed the library in such a way that makes it a little more REPL friendly. For example, we can create a small number printer system like so:
num = Numbers()
printer = Printer()
num.Out = printer.In
printer.Postfix = "/n"
Parallel(num, printer).Run()
All the channels are hidden inside the Plug and Play components. This also scales up for processes with multiple inputs and outputs:
num1 = Numbers()
num2 = Numbers()
num3 = Numbers()
plex = Plex()
num1.Out = plex.In
num2.Out = plex.In
num3.Out = plex.In
printer = Printer()
plex.Out = printer.In
printer.Postfix = "\n"
Parallel(num1, num2, num3, plex, printer).Run()
As I said, its more of a toy than anything, but it can be a little bit fun just plugging components together like this. We have also added an ability to create process like methods, although this is very dirty:
def Consumer(in):
def Con()
for i in range(10):
print in.Read()
return Con
def Producer(out):
def Prod()
for i in range(10):
out.Write(i)
return Prod
Parallel(Consumer(chan.In), Producer(chan.Out))
This is by far not an ideal solution, and Python was never meant for this, nor even .NET. It would probably woudn't be much to write an REPL that converted occam style code to this, but I don't think its a good idea. For one its incredibly slow in comparison to the Transterpreter (ranging from 5 to 10 times so), and secondly seems like a bit of a hack to me. It would be nice having an occam REPL, or something similar. All in all, it has been a nice little distraction doing this.
As for the future of the library, I'm not sure. We are presenting a paper this year, but it looks like some students from Compenhagen have also done a .NET library, and theirs includes networking capability. I'll hopefully have a chat to them and the conference and see what they've done. Also, there is a Java solution to this in the form of Bean Shell. This lets you compile Java code line by line so JCSP can be used (could never get the networked stuff to work unfortunatly). Hopefully this will be helpful to some.
Kevin Chalmers
Research Student
Napier University
-----Original Message-----
From: owner-occam-com@xxxxxxxxxx on behalf of Matt Jadud
Sent: Thu 17/08/2006 14:58
To: occam-com@xxxxxxxxxx
Subject: [Fwd: Re: my web site (fwd)]
Hi,
I'm newly added to the list; please excuse the delay in getting back to
you, Allan.
---------- Previous message ----------
From: Allan McInnes <amcinnes@xxxxxxxxxx>
I know that the Transterpreter group has developed a multi-platform
occam VM which runs transputer byte code, but I'm not sure if it
provides a REPL or not (I'd assume that the imperative nature of occam
makes a REPL less attractive). Perhaps if someone associated with the
Transterpreter is reading this they
could fill us in.
--------------------------------------
The Transterpreter is a cross-platform VM for executing compiled
bytecode. We currently do not have anything resembling a REPL built into
the VM simply because we do not, at this time, have a compiler capable
of operating in this manner.
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. I can imagine ways the Transterpreter could support this kind of
incremental development process, but it isn't terribly high on our
development wishlist---largely because we'd have to build the compiler
support, too. I mean, we could try and lean on Fred, or some other
member of the community, to build it, but really---if we wanted it, we'd
probably be expected to build that support into both the compiler and
interpreter.
So. It's interesting to think about, but we don't have a compelling
reason to put it on the roadmap, yet. We're open to discussion as to why
we should consider it, though.
Related, in a way:
It may be of interest to this list that the Transterpreter has now gone
open source, and an anonymous SVN now exists[1]. We aren't calling it
"1.0" yet (everything we want in place for a "1.0 release" isn't
complete), but decided it was time to open things up. We also have open
discuss and announcement lists, and a newly created 'tvm-dev' list[4],
for people who are interested in participating in the future development
of the platform. Currently, the 'dev' list is the most active, as we
have moved all of our internal, group development messaging to that
list. All of these lists are linked in from [2].
[1] http://www.transterpreter.org/wiki/SVN_Download
[2] http://www.transterpreter.org/wiki/Mailing_Lists