Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ames!uhccux!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.lang.lisp
Subject: Re: Total ordering for Lisp objects ?
Message-ID: <2092@munnari.oz.au>
Date: 13 Sep 89 05:12:49 GMT
References: <5896@lifia.imag.fr> <865@skye.ed.ac.uk> <2084@munnari.oz.au> <4932@ubc-cs.UUCP>
Sender: news@cs.mu.oz.au
Lines: 19

In article <4932@ubc-cs.UUCP>, morrison@grads.cs.ubc.ca (Rick Morrison) writes:
> In article <2084@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
> >But consider [code deleted]
> >The ordering of a and b has changed although a and b still point to the
   ***********************************************************************
> >"same" objects.
   ***************

> 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.

It has nothing to do with referential transparency.  The point is that
because Lisp has destructive assignment, it is not possible to define an
enduring total order on Lisp objects *based on their shape*.  My posting
was a follow-up to Jeff Dalton's where he was talking about a possible
total ordering based on the type and elements of objects (their shapes),
like the ordering used in Prolog.  My point is that a Lisp ordering *can't*
work _that_ way because the elements of objects can change.