Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!newcastle.ac.uk!turing!ncmh From: Chris.Holt@newcastle.ac.uk (Chris Holt) Newsgroups: comp.lang.misc Subject: Re: Some things that pointer-less languages can't do efficiently Message-ID: <1990Nov22.020446.17268@newcastle.ac.uk> Date: 22 Nov 90 02:04:46 GMT References: <26739:Oct1023:44:2690@kramden.acf.nyu.edu> <65450@lanl.gov> <10397:Oct1212:55:1090@kramden.acf.nyu.edu> <3975@goanna.cs.rmit.oz.au> <3716@skye.ed.ac.uk> <3808@skye.ed.ac.uk> Sender: news@newcastle.ac.uk Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE1 7RU. Lines: 28 There is a discussion here (if I understand it correctly) about how one can constrain two variables in such a way that a change to one will effect a change in the other. In particular, if a is set to a list, and b is set to the cdr of that list, then a change in b ought to cause a change in a. [This is my interpretation of the discussion between Jeff Dalton and Peter da Silva re: >>(setq a '(foo (bar baz))) >>(setq b (cdr a)) >>(rplaca b 'bog) ]. Since this sort of thing only makes sense in a temporal context, would it not be reasonable to view pointers/aliasing as the introduction of a temporal constraint, along the lines of: From time_current to time_end_of_scope Ensure b = cdr a together with the assumption that everything remains the same over time unless explicitly changed, or unless a change is needed to maintain the constraints? That is, rather than view b as a pointer into a, view it as a distinct variable that is constrained with respect to a? I find the semantics of the latter easier to understand (but what do I know? :-) ----------------------------------------------------------------------------- Chris.Holt@newcastle.ac.uk Computing Lab, U of Newcastle upon Tyne, UK ----------------------------------------------------------------------------- "He either fears his fate too much, or his programming tools are small..."