🚀 go-pugleaf

In article <=GH6UHD@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes:
|> In article <1990Oct15.204343.2907@arnor.uucp> lowry@lusitania.watson.ibm.com (Andy Lowry) writes:
|> > The Hermes programmer could represent a graph precisely in the
|> > standard conceptual manner--as a collection of nodes and a collection
|> > of arcs, where each arc is a record containing two node id's.
|> 
|> ...each of which node-ids is a pointer, no? It's not a machine address, but
|> its an identifier that can reference any arbitrary node... it's a pointer
|> into a bounded collection of objects, but you still have to worry about
|> aliasing within that collection. The problem of aliasing is alleviated,
|> but not solved.
|> 
|> (basically, you've switched from C to lisp)

Not really.  Just because I have the same integer value stored in two
different variables, does that mean they are aliased?  Just because I
have the same node ID stored in two different variables, are those
variables aliased?  I can change one without the other being affected.
I would say they are not aliased.  Hermes guarantees that it is
impossible to change the value of one variable as a side-effect of
changing the value of another.  This is what we mean when we say
Hermes does not allow aliasing.

In Lisp, this is not the case.  I can write:

	(setq x '(1 2 3))
	(setq y x)
	(rplaca x 'a)

It's true that if x and y contain node ID's, then I can retrieve the
node identified by x and change it, and now if I retrieve the node
identified by y I will see the change.  But I did not change the value
of y.

Perhaps one could say that the distinction is a bit muddy, and a
stronger guarantee than the one we make might be useful in some
situations.  Nevertheless, the guarantee we do make is extremely
useful, in that it enables our compiler to perform very strong checks
to ensure that no Hermes process can ever affect another in a way that
could not have been anticipated by looking at the code, knowing
nothing of the underlying implementation.  For example, a bug in one
process can never cause random behavior like crashes to occur in other
processes, even if they are executing in the same address space.  In
addition, though we have not explored this to any great extent, we
believe that our non-aliasing guarantee will enable many compiler
optimizations that cannot be performed in the presence of aliasing.

-- 
Andy Lowry, lowry@ibm.com, (914) 784-7925
IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10598