carriero-nicholas@CS.YALE.EDU (Nicholas Carriero) (01/10/91)
A few comments in response to some recent postings: 1) inp/rdp: As Jerry implies, this was something I snuck into the shared memory system because it could be done *and* there was some perceived need for the functionality. I no longer use inp/rdp and I encourage others not to. We would still like to provide some kind of similar functionality in a manner compatible with core Linda. Some ideas have been mooted, but no convincing candidate has emerged. 2) eval: There seems to be three issues here: i) Definition. ii) Implementation. iii) Enforcement. David has answered i). There is a definition. It has been pointed out, correctly, that there is variation in, at least, the Yale implementations. From this you may infer what you will, but the mundane explanation is simply that I have not bothered to clean things up. The varying implementations provide enough commonality of functionality (and are sufficiently faithful to the definition) that if you design to the definition, your codes work and are portable. (An exception: as Narem reported, some systems do not generate a new thread for every function call in an eval. This is a serious flaw that can lead to deadlock. As it happens, no one pounded sufficiently hard on my door to have it fixed, so I let it slide. This exchange has prodded me to fix it---thanks for the push.) Enforcement: the definition is not structured as "foo and nothing but foo". Thus, it is entirely possible that a program could have processes that are able to side effect other processes. So, for example, on a shared memory multiprocessor, if you want to explicitly use shared memory as well as Linda, you can. Granted, there is more to the enforcement issue, but it is important to set this issue apart from the others and give some sense of how we approach it. One important question: if you *don't* intend for such side effects to happen (and by default, we hope you don't), how much help can the system offer in uncovering unintended instances? We are working on this and have made some recent progress (again motivated by this discussion) on providing "clean" copies of the process image for newly eval'ed functions. Much of Steven's posting seemed either to present the opinions of those who prefer a different definition (e.g. Jerry), instances of variations in implementations, or issues of enforcement in the guise of process side effects (btw, the quote about friction is out of context---it was meant to illustrate the desirability of working with side effecting computational languages (C, FORTRAN) in parallel systems rather than forcing parallel work into the functional mode). Certainly, Steven made other points, but the eval issue seemed particularly in need of "clarification" as the impression may have been created that all was chaos and that Linda programmers were consumed with beating recalcitrant evals into submission. 3) Ease: As I understand it, Ease is in the very early implementation stages. Claims like "the Ease model is inherently more efficient" are terribly easy to make when you don't have to measure anything because you don't have anything to measure. I am sure Steven understands this; as he points out the ultimate test is to go head to head with Linda and other systems. We eagerly await this.