NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/parallel/1795

Text File | 1992-07-24 | 3.7 KB | 83 lines

Newsgroups: comp.parallel
Path: sparky!uunet!gatech!hubcap!fpst
From: [e-mail] (Matthew Huntbach)
Subject: Re: CSP to STRAND/Parlog
Message-ID: <[e-mail]>
Sender: [e-mail] (Usenet News System)
Nntp-Posting-Host: tea.dcs.qmw.ac.uk
Organization: Computer Science Dept, QMW, University of London, UK.
References: <[e-mail]>
Date: Fri, 24 Jul 1992 10:48:39 GMT
Approved: [e-mail]
Lines: 69

From: Steven Zenith <[e-mail]>
>In article <[e-mail]>, [e-mail]
>Matthew Huntbach writes:
>
>> If you think that Strand or Parlog are basically
>> "parallel Prologs", you are completely wrong. Many people who
>> program in them, such as myself, think of them more in CSP-like
>> terms than in Prolog-like terms.
>
>I'm pleased to hear it, I don't dispute that a parallel between CSP and
>Strand or Parlog can be drawn - but you don't answer my question: why is the
>parallel between committed choice concurrent logic languages closer than any
>other (say, CSP and functional or concurrent imperative languages)?

The parallel is shown by the name the ICOT team gave to their
version of the language "Guarded Horn Clauses". The Guarded
clauses which from the basis of Strand/Parlog/GHC are
very similar (in fact taken from) the guarded commands of CSP.

The logic variables of Strand/Parlog/GHC can be used as
CSP-like channels. A logic variable shared between two
processes (a term which many Strand/Parlog/GHC programmers
prefer to the logic-oriented "goal") may be consideed as a
channel. Suppose we have two processes p(X,C),q(C,Y). If the
process p(X,C) binds C to [message|C1] i.e. a list with unbound
tail, and rewrites recursively to p(X,C1), it has in effect
sent a message over the channel C to the q process. The q
process is effectively suspended waiting for this message if it
rewrites using a clause of the form:

q([H|T],Y) :- process(H),q(T,Y).

since a Strand/Parlog/GHC goal will not rewrite until its
arguments are sufficiently bound for it to be able to commit to
a clause without any outwards unification.

These things are not CSP-like elements bolted on to a language,
they are what Strand/Parlog/GHC are all about. That is why I
see these languages as essentially logical CSP.

>It wasn't clear from your earlier posts that execution was your primary
>interest. I'm still not sure that if I was considering a target language for
>the execution of CSP scripts that STRAND or Parlog would be a good choice.
>So, we should clarify what you are interested in when executing CSP scripts.

A CSP script translated into Strand can be tested by executing
it. As a logic language, Strand programs are open to program
reasoning and transformation techniques in a way which CSP
scripts are not. I find it far easier to see what a Strand
program is doing than what a CSP script is supposed to do. In
fact, it's difficult to see why anyone should bother with CSP
at all when Strand is easier to program in, easier to reason with
understand, and just as powerful.

As an illustration, one of my recent pieces of work has been to
take an algorithm written in CSP (Lavallee and Roucairol's
Minimum Spanning Tree algorithm in Information Processing
Letters 23 (1986) pp.55-62). I hand translated it to Strand,
which instantly revealed a number of small errors in the
specification, instantly explained to me what it actually did
(I was very unclear when I just looked at the CSP) and enabled
me to hack around with the Strand code for a bit to produce a
much improved version of this distributed minimal spanning tree
algorithm (Technical Report giving more details available from
me at Queen Mary and Westfield College, Dept. of Computer Science,
Mile End Road, London E1 4NS, UK).

Matthew Huntbach