Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!dan%@@uunet.UU.NET
From: dan%@@uunet.UU.NET (Daniel Cohen)
Newsgroups: comp.sys.transputer
Subject: Re: STRAND88
Message-ID: <9002060301.AA01527@>
Date: 6 Feb 90 03:01:47 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 91


Nick Rothwell writes:

	Sounds just like Shapiro's Concurrent Prolog to me. Concurrent Prolog
	is quite nice (as long as you don't want to backtrack, since it
	doesn't), but it has some flaws, such as the fact that the guards are
	supposed to execute (and unify) without affecting the rest of the
	system, and I could never figure out a way of ensuring this without a
	huge overhead (Shapiro's papers seem to punt on this one); so, my
	compiler didn't bother. Does Strand deal with this?

Yup, Strand guard tests are NOT general-purpose Strand procedures;
they are all kernels ( ie. not written in Strand ) which cannot
assign variables. We believe this is essential if the language
is to run efficiently.

	If Strand is aimed at a local-memory model of computation, how is
	store management handled? (not to mention chains of unification and
	all this nasty stuff.)

Another surprise for Prolog fans ( like me ) - no unification!
Strand matching is one-way only, forcing the programmer to think
more about inputs and outputs. Incomplete structures can still
be used ( as when one process sends an incomplete message to
another, for the latter to fill in the result ), just it won't
all be done in the head-matching phase ( same restriction as for
the guard, really - no assigning variables until a clause has
been selected ). This is why Strand 'feels' like a dataflow
language, rather than a logic-programming language.

	What sort of type system does the language have? Polymorphic? Dynamic?

Polymorphic

	Does it address the problems associated with programming in the
	large (modules, interfaces, abstraction)? - or is that outside its
	scope?

There is a module system which is smart enough
to load modules automatically when they are required.
We included fast foreign function interfaces ( currently C
and Fortran ) at the abstract machine level ( ie. programmers
can write their own guard and body kernels in, say, C )
because many users want to use Strand as a 'harness' for
running conventional code in parallel; we hope to extend
the range of interfaces in the future ( eg. we already
have some material for X-Windows output ).
I'm not quite sure what you mean by 'abstraction' here.
We liked Strand because it seemed like a good language
to build up on - object-oriented systems; rule-based
systems etc. but most of this work is still at a conceptual
level ( except objects ). There's also been a lot of work
done on programming methodologies which should eventually
result in some dataflow and/or object-oriented CASE tools.


	>Strand is good for parallel programming because of its' computational
	>model; a program runs by the repeated reduction of processes - when
	>one process is reduced others may be spawned - until the processes
	>are defined by built-in kernels.

	This sounds like parallel combinator reduction, which is fine as an
	intermediate form but I don't know if I'd like to program that way.

We can supply STRAND88 on 'test drive' on Sun's, if you'd
like to play around with it ( unfortunately we have to
charge for the media and materials ). But why don't you
get hold of the book by Foster and Taylor:
"Strand: New Concepts in Parallel Programming"
( Prentice-Hall ISBN 0-13-850-587-X; contact us if you
can't find it ). That should give you a feeling for what
it's like to program in Strand.

Someone else asked for some references to Strand;
I'll collect a list and post them next week.

	Could you post some examples of Strand programs? (Do you have a
	mailing list, electronic or otherwise?) It's interesting to hear what
	it can do, but that's not much use without some actual examples of
	code to illustrate some of the above points.

Will do, when I have time! Or else send me a message,
and we'll send you some literature.

Daniel Cohen
Strand Software Technologies Inc.
15220 NW Greenbrier Parkway, Suite 350
Beaverton, OR 97006, USA
Tel: +1 (503) 690 9830

e-mail: dan%ssti@uunet.uu.net  or  uunet!ssti!dan