Perhaps the semantics should be discussed. What should the behavior of the following be (also ignoring syntax issues):
global xref
procedure f(a) xref := &a
a := 3
end
... write(*xref)
Logically, it makes the most sense that when a variable goes out of scope, all its references should become invalid and therefore the above dereference fails.
and
procedure g() yref := &xref *yref := &yref write(*xref) end
I don't see any source of ambiguity here. This is equivalent to:
yref := &xref xref := &yref write (yref)
... and then yref goes out of scope, and *xref becomes invalid.
The only other detail is how a reference gets stringified by write. (a pretty minor detail)
There are reasons why functional languages don't like reference types - they can be addressed, but it needs careful thought.
I don't really see Icon as being a functional language. Certainly, many of its interesting features are imperitive in nature.
Languages like C and FORTRAN operate under a 'caveat emptor' philosophy that isn't appropriate for languages like Unicon.
Which is why invalid references would have to be checked. This might impose a performance penalty on the use of references, but that's consistent with the design of other language features.
Louis
------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
