kale@kale.cs.uiuc.edu (L. V. Kale') (05/11/89)
kale> programmers ALREADY know that. Linda simply forbids them from
kale> stating it!
Carriero> Not true (As Moshe Braner has pointed out). If A wants to send to B,
Carriero> A writes out("B",...) and B executes in("B",...).
I did not say that process A cannot send message to process B (with Linda).
Obviously it can.
But what is "B" in your example above? A constant string? That doesn't
work for recursive structures (see my response to Moshe Braner).
Some sort of instance specific ID sent by B to A?
Well, sure, that achieves the effect of sending a message to a
specific process.
But as "B" is just another tag (which happens to simulate instance ID),
the programmer has not been able to directly tell the system
to send the message to a specific process, when he/she could have.
The compiler may (or may not) be able to detect and optimize this
situation on a message passing machine (but that is secondary to the
point I am making). When one is allowed to say "send this message to the
process with this ID", the system may use its knowledge about process
IDs to carry out the communication efficiently.
---------------------------------------------------------------------
kale> [Assume that variables of dynamic table type subsume the
kale> functionality of tuple spaces ]
carriero> Given the above, we're not inclined to take you word for it.
carriero> Can you store processes as entries in your dynamic tables?
(a) The original motivation for dynamic tables was preventing
duplication of work in search /funcitonal/ logic programs.
So, we have to have processes suspending on specific entries in the
table. (We have had the requisite algorithms for a long time. The
implementation will come shortly to message passing machines).
Processes turning into tuples is cute (and a nice metaphor), but you do
not need that to subsume the fucntionality.
(b) *More important*: I just asked the reader to take my word that such
variables CAN be implemented. The main point is not whether we are
smart enough to implement it.
Rather: is it better to use the generality of
tuple space operations for all situations?
Or is it better to use such operations only when they are needed?
I believe the latter, and I'd like to see some debate on that.
----------------------------------------------------------------------
> Speculative arguments about Linda's efficiency are irrelevant;
I'd sincerely like to be educated about Linda implementations on hypercubes,
and what sorts of applications have been run on it, etc.
Given that Linda is machine independent, do all Linda programs that
run on shared memory machines run efficiently on hypercubes?
Can you point to some references etc.?
The ones I have seen (e.g. DNA matching using the N^3 matching algorithm)
are too simple to learn about the power of the system/language.
----------------------------------------------------------------------
> your argument amounts to the following: "if
> tuple space is good, tuple space plus 5.5 other things is even better".
> But unfortunately, making simple things complicated is not a
Having a single "goto" statement is not better than having separate
if-then-else, while, repeat, and loop-exit statements.
I am not arguing for 5.5 arbitrary primitives.
I am arguing for the idea of having specific primitives for
specific and distinct ways of sharing data.
Tuple space operations (or dynamic tables) will be just one
infrequently used but nonetheless important feature in such a system.
> ..program in languages that provide optimized support for a few simple tools
I believe in few simple tools too. But a chainsaw for everything?