Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!unmvax!gatech!hubcap!bjornl
From: bjornl@tds.kth.se (Bj|rn Lisper)
Newsgroups: comp.parallel
Subject: Re: "Molecule: Language Construct for Development Parallel Programs"
Message-ID: <5599@hubcap.clemson.edu>
Date: 25 May 89 12:10:26 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 35
Approved: parallel@hubcap.clemson.edu

In article <5593@hubcap.clemson.edu> cline@sunshine.ece.clarkson.edu
(Marshall Cline) writes:
....
>Did ya'all see the article in May's IEEE Transactions Software Engineering?
>	"Molecule: A Language Construct for Development of Parallel Programs",
>	 by Z. Xu & K. Hwang, pages 587-599.
....
>__________WHAT_IS_A_"MOLECULE"?_______________________________________
>			.....  By "non-strict dataflow", they mean the
>single assignment rule for _atomic_ objects; ie: if "i" is an integer,
>it can be assigned a value only once, but if "a" is an array of integers,
>each element can _individually_ be assigned a value, but only once.  No
>lazy evaluation specified.

Very interesting. I've always considered the approach to treat whole arrays
as atomic entities in single-assignment languages as a failure, since it
lends itself to potentially very inefficient implementations (like copying
whole arrays, or using costly I-structures). The problem is, however, to
find that a given program with assignments of single array elements really
adheres to the single-assignment rule. In quite a few cases this can be done
by a compile-time analysis; in others it's not possible, like in the
following example:

a(f(i)) = x
a(f(j)) = y

where f is an array whose entries are unknown at compile time, so that
possibly f(i) = f(j). The "whole array" approach takes care of this by
demanding the two assignments to assign different arrays. In the "array-
element-as-atomic-entity" approach one has to provide some run-time
mechanism to check for single-assignment consistency.

I think, however, that this is the way to go.

Bjorn Lisper