Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ames!haven!purdue!decwrl!hplabs!hp-sdd!ncr-sd!ncrcae!hubcap!lbo
From: lbo@ztivax.siemens.com (Dr Lothar Borrmann)
Newsgroups: comp.parallel
Subject: Re: eval() in Linda
Keywords: linda parallel
Message-ID: <4318@hubcap.UUCP>
Date: 6 Feb 89 13:10:04 GMT
Sender: fpst@hubcap.UUCP
Lines: 61
Approved: parallel@hubcap.clemson.edu

In article <4282@hubcap.UUCP> budd@mist.cs.orst.edu (Tim Budd) writes:
>[ Is there a newsgroup specifically devoted to discussion of linda? ]

There has not been too much discussion about Linda in *this* group 
during the last months. It seems that there is nobody interested (?).

>In implementing Linda, one of the more difficult problems would seem to be
>the correct handling of eval().  I'm particularly curious as to how eval()
>is done in systems such as Leichter's VAX/VMS ethernet implementation,
>where it is not possible to simply fork off a child of the process on one
>machine and expect that it will take up residence on a different machine.
>Do they just punt and not implement eval?

According to Sudhir Ahuja, Nicholas Carriero and David Gelernter in 
*Linda and Friends* (Computer, August 1986) this call is not considered
as primitive but can be implemented on top of *out*. 
When we started *our* Linda work (on top of Modula-2)
we heard from Yale that eval implementation had been postponed 
in *their* Linda systems.
However that was about 18 months ago.
In our system we distribute work just by OUTing application dependant
'task descriptions'. You may regard such a tuple an 'active' one.
The task specification can contain ordinary data as well as the key 
for a procedure to be called. Even procedure parameters could be
included, in case this procedure does not access global data.

>I've never been exactly certain of the exact semantics of eval, either.
>Here are two questions:
>
>1. Can an eval'ing process in() it's own tuple?  does this have any effect
>on the executing computation?  That is, can I do something like
>
> ( ... example deleted)

This looks strange.

>
>2. When using typed fields, is it the case (as one would expect) that 
>the type of a running process produced by an eval is different from the
>type of the result produced when that process completes?  That is, if 
> (...)
>the in() should hang until bar is finished, since prior to that point
>the type of the second argument in the typle is a process.
>Is my understanding correct?
>
We would think so too.

However it seems that David Gelernter should be asked to point out
the definite semantics of eval as well as the state of work to 
implement it. A followup from Yale would be appreciated, I think.

_____________________________________________________________________________

Lothar Borrmann                      Email:
Siemens AG                            UUCP    lbo@ztivax.uucp
Corporate Research and Technology      or     ...{uunet}!unido!ztivax!lbo
ZFE F2 SYS 3                                
Otto-Hahn-Ring 6                       Internet   lbo@ztivax.siemens.com
D-8000 Muenchen 83                     or         lbo%ztivax.uucp@uunet.uu.net
West Germany
_____________________________________________________________________________