Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site arizona.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!arizona!kelvin
From: kelvin@arizona.UUCP (Kelvin Nilsen)
Newsgroups: net.lang
Subject: Assignment-by-reference - a query
Message-ID: <28826@arizona.UUCP>
Date: Tue, 7-Jan-86 13:35:18 EST
Article-I.D.: arizona.28826
Posted: Tue Jan  7 13:35:18 1986
Date-Received: Wed, 8-Jan-86 06:22:33 EST
Distribution: net
Organization: Dept of CS, U of Arizona, Tucson
Lines: 69


i am designing a language for use in programming data communications
applications such as file transfer, network prototyping, logon scripts,
more sophisticated scripts, ...

although its forefathers would probably disavow any association with this
beast, it has strong similarities to both SNOBOL and ICON.

one feature which is particularly dangerous is the idea of "assignment-by-
reference."  any assignment of the form (a <- b) simply gives 'a' a pointer
to the same data that 'b' is pointing to.  so in the following sequence of
code:
		b <- 3;
		a <- b;
		b <- 5;
		write(a);

the number 5 is written to stdout.  of course, :-) this is often not desirable 
behavior.  more traditional behavior could be obtained by rewriting the code:

		b <- 3;
		a <- `b;	/* the grave accesnt causes a 
					copy of 'b' to be made
				*/
		b <- 5;
		write(a);

the proposed semantics for this wierdness is such that each time a new item
joins a group of aliased variables, the entire group takes on the value 
represented by the right-hand-side of the assignment.  so if we append to 
the first version of the above code, the statements:

		c <- 7;
		a <- c;

now 'a', 'b', and 'c' all represent the number 7, and changing any one of
them will change all of them.  To back variables out of this shared 
relationship, nullify them one by one.

implementation of this relies on several levels of indirection existing
between a variable and the data that it represents.  this is more costly
than what is done for standard compiled languages, but typical(?) of high
level languages such as ICON and SNOBOL.

motivation for this is several fold.  in ICON, there are inconsistencies
in the treatment of structured objects and scalars. for example, in the 
code:
		t := s
		s[5] := 'c'

the variable 't' will feel the effect of the second line's assignment if
's' represents a list, but will not if 's' is a string.  my intention is
to unify such behavior.

also, as CommSpeak was designed with real-time programming on microcomputers
in mind, it is strongly typed.  Assignment-by-reference was proposed in hopes
of buying back some of the flexibility of late binding and deferred evaluation
which are available to varying degrees in both ICON and SNOBOL.

my quandary:
	have any other languages been plagued by this same blunder?  
		any papers describing the experiences, feelings of the
		language designers in retrospect?
	does anyone have a suggestion for revised semantics of assignment 
		that might satisfy the same needs with less "astonishing
		results" to the unsuspecting programmer.

thanks for your thoughts,
kelvin nilsen