Subject: more on the intro

From: Steven Ericsson Zenith <[email-masked]>
Date: Tue, 24 Nov 92 16:14:36 -0600

Concerning the introduction:

	"The paradigm will not be made obsolete by architectures combining the shared-
	and distributed-memory views, or by increases in network speeds."

I think this sentence is unnecessarily defensive. I'd delete the sentence
and the following "thus".

I earlier raised an objection to 

    \item  A simple way to create processes for the SPMD model

there seems to be some redundancy here with

    \item  Process groups

The former is a subset of the latter. I'll repeat my noncirculated
comments: I would rather not see us say too much about the process model
at this stage; except to say that there is some process model defined by
the language using the standard and to say something about side effects
between processes that affect the message passing semantics (i.e., that
there should be none). That does, of course, leave us with some
interesting problems for identifying our communication; traditionally a
difficult subject in message passing (hence my distribution of this
message to the whole committee).

The easy route would be to have a global name space of shared "channels"
each with a communication characteristic [type] (e.g., "point-to-point"
or "one-to-many"): a compiler can check correct usage if we identify the
right rules (e.g. a synchronized unidirectional point-to-point
communication is shared by only two processes). Such logical naming
would map well across all the existing systems and avoid the problems of
name servers, processor id, topologies and so forth since any topology
can be described by the set of names and its users. Processor ids are,
in effect, names in a global name space - and are often channels that
have a "many-to-one" characteristic.

Steven