Language bias

[Chris Harris]

On Tue, 17 Jan 1995, Dr. J. Van Sckalkwyk (external) wrote:

> Dear Chris
> 
> >     The basic unit of "stuff" in the system is the cell.  A cell can be 
> > thought of as a "black box", with a number of unidirectional inputs and 
> > outputs.  A cell's output depends solely on its inputs.  (In other words, 
> > cells can't hold any data inside them.  This might be an arguable point, 
> > but its just the way I was thinking of it.)
> 
> I'm fairly happy with this. The good bit is that you mayn't have to 
> duplicate cells if multiply invoked by other processes.

Well, that, of course, depends on how you impliment things.  I guess the 
system call, or whatever you do to create connections between cells, 
could create new sets of inputs/outputs for each cell that links to 
another.  Doing this automatically might be a bit evil, though, for cells 
that should only be accessed by one other at a time.  Or would this need 
ever arise?

> >     Internally, cells are composed of a group of primitive cells 
> > (support provided by the language), as well as any found useful in other 
> > cell libraries.
> 
> A question. Is the Russian doll structure necessary? i.e. just 
> because your basic unit on this level is the cell, why not consider 
> the possibility of having other constructs at lower levels?

That would probably be a wise idea; I'm just caught up with all-enclosing 
concepts these days....  If others wish to propose another sub-cell unit, 
I'd certainly be willing to think about it, but I think we should also 
support cell-enclosing cells.  (If Mike were here, I bet he'd tell me 
such cells are best implimented on a high level, and I'm not sure if he'd 
be wrong.  Since the sub-cells could depend on on a subset of the 
super-cell's inputs, they could just be attatched to the same 
connections.  If those are implimented as shared variables, I doubt it'd 
be too slow - its faster than a message send....)

> >     I'd imagine that a number of people are already griping about how 
> > such a system could possibly go fast enough.
> 
> This is not necessarily a problem at all. Optimisation is usually 
> best applied to small critical portions of code. Provide we do not 
> slavishly apply homogeneous constructs at all levels, the system will 
> work well.

This is the point I find myself forgetting frequently.  I guess I haven't 
done enough low-level design.  =)

> >     The other point people will be complaining about is how to represent 
> > current-style programs in this new system, as it will probably take 
> > people longer to think up a good distributed algorithm than a sequential 
> > one.
> 
> Are the two approaches necessarily mutually exclusive?

No, not necesarily; people often spend many hours of their time to make 
their sequential app work in parallel, while keeping certain parts 
sequential.  This enviornment, though, should make it as easy as possible 
to create parallel apps, to promote taking advantage of all availible 
resources, while at the same time retaining some ability to use 
old-fashioned sequential code.  I think the latter should be create with 
constructs imbedded in the former, but this might have to die if its too 
slow.  =(

Anyone else have thoughts on this?

-Chris