Path: utzoo!utgpu!watmath!watdragon!akwright From: akwright@watdragon.waterloo.edu (Andrew K. Wright) Newsgroups: comp.lang.misc Subject: Re: Alternatives to refs Message-ID: <10134@watdragon.waterloo.edu> Date: 1 Dec 88 18:51:14 GMT References: <388@ubbpc.UUCP> <16187@agate.BERKELEY.EDU> <599@quintus.UUCP> <591@tuck.nott-cs.UUCP> <404@ubbpc.UUCP> <7774@aw.sei.cmu.edu> < <594@tuck.nott-cs.UUCP> Reply-To: akwright@watdragon.waterloo.edu (Andrew K. Wright) Organization: U. of Waterloo, Ontario Lines: 86 In article <594@tuck.nott-cs.UUCP> anw@maths.nott.ac.uk (Dr A. N. Walker) writes: >[Clay Phipps (>>) and Steven Ryan (>) are surprised that: > >> begin int I := 0, K := 1; > >> ref int Ptr := I; > >> Ptr := K; > >> Print (I); > >> end >prints 0 rather than 1.] > > Perhaps I'm being dense, but I would have been totally astonished >had it been otherwise. Let's take it steadily: > > int I := 0, K := 1; > # find me some local places suitable for holding two ints, > label them I and K, and initialise to 0 and 1 # > ref int Ptr := I; > # find me some local place suitable for holding a ref int, > (ie, for holding a place suitable for holding an int), > label it Ptr, and initialise to the place (the ref int!) > that we labelled I # I agree that this statement should have the interpretation you give, but the issue is confused (i think) by the declaration. Lets separate the two: ref int Ptr; -- ignoring initialization Ptr := I; Now this last statement could be assigned two possible semantics. 1. the space named Ptr is assigned the address of the space named I. 2. the space pointed to by the space named Ptr is assigned the value extracted from the space named I. I will the call the first one "shallow" semantics, and the second "deep" semantics. In general, you can have graduation of deepness if you have more ref's involved. The confusion arises because both the "address of" operation and the "indirect through" operation are implicit. C deals with the problem by making almost everything explicit. "address of" is always explicit, and MORE THAN ONE indirection must also be explicit (one indirection, converting an lvalue to an rvalue, is implicit, and always performed unless & is present (except for arrays and functions)). The C equivalent is int I; int *P; P := I; -- is illegal P := &I; -- shallow *P := I; -- deep Algol-68 deals with this problem by introducing the rule that dereferencing is never implicitly performed on the left hand side of :=. >> [suggestion for "var" and "ref" ... example including: >> var ref int Ptr = loc ref int := address I; We have toyed with this idea in designing a new type system. Rather than saying that "var" is a variable; however, we prefer to say that it is very similar to "ref", but that there is automatic devar'ing, and no automatic deref'ing. := requires that its left operand be of type "var something". devar'ing is preferred where possible. var something can be automatically converted to ref something, but not the other way around. Then if you write var int I; var ref int P; P := I; -- shallow meaning, same as P := (ref int) I; (var int) P := I; -- deep meaning assignment to P by default has shallow meaning, like Algol-68. On the other hand, var int I; var var int P; P := I; -- deep meaning, same as (var int) P := I; (var ref int) P := I; -- shallow meaning assignment to P by default has deep meaning, as Clay Phipps and Steven Ryan expected. This is not to say that by introducing "var" we have forgotten about the similarity between pointers and variables exemplified by Algol-68; we think they are similar, not identical. "var" types allow us control over the differences. Comments? Problems? (we have a few, but I will keep them to myself since this posting has become long enuf) Andrew K. Wright akwright@watmath.waterloo.edu CS Dept., University of Waterloo, Ont., Canada.