Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!grads.cs.ubc.ca!morrison
From: morrison@grads.cs.ubc.ca (Rick Morrison)
Newsgroups: comp.lang.lisp
Subject: Re: Total ordering for Lisp objects ?
Message-ID: <4932@ubc-cs.UUCP>
Date: 12 Sep 89 20:56:06 GMT
References: <5896@lifia.imag.fr> <865@skye.ed.ac.uk> <2084@munnari.oz.au>
Sender: news@cs.ubc.ca
Reply-To: morrison@grads.cs.ubc.ca (Rick Morrison)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Lines: 21

In article <2084@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
>But consider
>        (let ((a (list 1))	        ; fresh copy of (1)
>              (b (list 2)))             ; fresh copy of (2)
>	    (print (total-less-p a b))  ; prints T
>	    (setf (car a) 2)            ; now a is (2)
>	    (setf (car b) 1)            ; now b is (1)
>	    (print (total-less-p a b))) ; prints NIL
>The ordering of a and b has changed although a and b still point to the
>"same" objects.  (Think about one stack group trying to sort a list while
>another is happily mutating it...)

I don't get. How does this argue against defining a total ordering
on LISP objects? Admittedly the above example violates referential
transparency, but this is a result of the use of destructive assignment.
-----------------------------
Rick Morrison		 | {alberta,uw-beaver,uunet}!ubc-cs!morrison
Dept. of Computer Science| morrison@cs.ubc.ca
Univ. of British Columbia| morrison%ubc.csnet@csnet-relay.arpa
Vancouver, B.C. V6T 1W5  | morrison@ubc.csnet (ubc-csgrads=128.189.97.20)
(604) 228-4327