[gclist] Reference counting on the fingers of one thumb.

[Amit J Patel]

[My reply is a little late!]


John Carter wrote to us on January 13:
> Greetings Collectors,
> 
> I have been contemplating designing a new programming language.

Hooray! :)

> One of the ideas I have been having results in a unusual form of
> garbage collection.
> 
> I thought I would bounce this idea of the esteemed members of the list
> and see if I can learn anything from the hisses and boos.

I hope you don't mind if this non-esteemed member of the list comments..

> My idea is that the programming language should enforce a "one object,
> one place" world view. (I'm in my office now, I can't be in the office
> and in the bathroom at the same time.) The reason for trying to do
> this, is the "one-object one place" paradigm is something our minds are
> trained on since toddlerhood. (The block is on the floor, it is no
> longer in my hand, WAAAH!) Thus I argue, if the computer world
> mimicked our spatial world more closely we would tend to create fewer bugs.

I agree completely.  However, you may not want everything to be an
object in this kind of language.  What is the `place' for the string
"hello, world"?  Does 3 have a location?  (I would argue that these
are not objects, but rather that they are values, or references to
Platonic objects.)

> I propose that assignment ALWAYS means deep copy. In other words, if
> we say a:= b, a becomes a complete copy of b, including copying any
> sub-objects of b or pointed to by b. I also propose a new
> assignment-like operator which I will call "handover". Instead of
> copying the value of 'b' to a, it will handover the object in 'b' to
> 'a'. Thus 'b' loses its binding and the 'a' takes it over. Thus the
> swap becomes
>   b handover to temp;
>   a handover to b; 
>   temp handover to a;
> 
> At the end of this sequence, 'temp' is unbound and it is illegal to
> refer to it.

I can't agree with this.  When I'm trying to mimic the spatial world,
I have to eliminate copying.  I can't copy myself; I can't copy my
office; I can't copy my car.  A few objects (such as papers and disks)
allow copying, but copying them is not a primitive operation, so I
don't mind if the language does not support copying objects.  Deep
copying does not make sense to me when looking at the real world.  (In
fact, I'd argue that objects can't be copied at all; a photocopy of a
piece of paper is really a different paper object that has the
contents of the first printed on it.)

[snip]

> I propose to resolve these problems by imposing the well-known
> database rule. "One fact in one place." I propose that all objects
> should be atomic in the sense that they can only be in one place, accessed
> via one name at a time.

> This will be made possible by the "assignment is deepcopy" rule and the
> "handover" operator. There will be no address-of operator. There will
> be no way of creating an alias. 

I view names (variables) as references to objects, not the objects
themselves.  Therefore when you copy 'a' to 'b', you are copying the
reference, not the object.  Of course this is going to make aliases,
but it seems _less_ global to me than having one name per object.  I
can refer to you as John Carter; your friends might refer to you as
John; and other people may have various nicknames for you.  There's
not one name for your object.  Conversely, the same name may refer to
many objects -- for example, I know another John Carter.  I need to
have local names to refer to different people differently.  I might
call you "John Carter" and him "John"; another person might call you
"John" and him "John Carter".

> Clearly the language should provide some form of indexed
> container. (An array being the archetype). Now the "one object one
> place" rule will insist that if we place an object into a container,
> we "handover" the object to the container. Thus the object is now in
> the container and is no where else. The handover operation ensures that
> the variable holding the object previously, is now unbound, and the
> object is no longer accessible via that route. The only way of
> operating on that object is via the container. 

I would like to page you without knowing which container you are in.
I want an alias for you that doesn't involve knowing where you are.

Another example is a program accessing some file on the disk.  If I
move the file into a different folder, I want that program to still
access the file; it shouldn't have to know that the file has 'moved'.
(Most OSes don't give you this, unfortunately.)

> Now the integer index of the object in the container provides all the
> functionality of a traditional pointer, but in a local, not global
> namespace. It is also just a plain old integer, and hence is amenable
> to all the fun things one can do with integers.

What fun thing would you like to do with this integer?  :)  I can't
think of anything really useful to do with it.  If I have a reference
to you (your room + your integer), does it help to multiply your
integer index by four?  Or see if it's prime?

What if the room contains {0:John Carter, 1:Table}, and then later
contains {0:John Carter, 1:Computer}?  Does the '1' referring to the
table have anything to do with the '1' referring to the computer?  How
do you invalidate all the objects that are storing the information
(Room, 1) so that they know that the table is no longer there?

> However, and this is the cute bit, we need to know the name of the
> container AND the integer index to access our object. Thus as soon as
> we move out of scope for that container, the container AND ALL THAT IT
> CONTAINS, becomes garbage and can be collected.

I would also like to have containers that have references (aliases) to
other objects.  For example, a list of all the books that I own.  Do I
need to store a pair (room, index) for each book?  What if the book
moves?  Why should my list have to change?  The traditional
pointer/reference model is good for things like this.

> What this rule does do, is create an object world that is far more like
> the familiar spatial universe we ourselves exist in. I can be in my
> office or I can be at home, I can never be in both. Thus when writing
> programs under this draconian constraint I am operating in an
> environment similar to the every day one.

I think it'd be nice to have a language that distinguishes two kinds
of variables -- "contains" and "refers to".  What you've described
would apply only to "contains" variables, and traditional variables
would be "refers to".  It'd make it easier to write visualization
tools; it could make memory management easier; and it could make it
easier to understand the structure of the program.  

Have you done any more designing for your programming language?


	- Amit



-- 
Amit J Patel, Computer Science Department, Stanford University 
       ``A language based on point and click is like a 
         human language based on point and grunt.'' -- me