🚀 go-pugleaf

In article <9235215.11144@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
|Why would ptrcmp() be practically unsupportable in these environments?
|OODBMS's maintain an object identity for each object, so it should be
|possible to base a total ordering on this object identity. I don't see
|the problems. What makes it difficult for Lisp machines? Are efficient
|BTrees and such-like genuinely impossible on such machines?

Of course BTrees and such-like are NOT impossible -- you just don't
base them on pointers!  You base them on some other well defined total
ordering of the objects, such as based on object surrogates.

Consider the case of OODBMSs where you use virtual memory schemes
to trap on pointers to objects not in memory and then bring such
objects into memory.  Such objects have unique [large] obids globally
identifying them, and smaller pointers [addresses] to them in their
current incarnations in memory.  Granted that an inverse mapping can
give you the obid from the pointer, its just that such would typically
be very slow compared to the address comparisons you expect.  Slower
than using surrogates for example.  So why not use surrogates?

|The function should be named after its interface, not its implementation.
|The function takes two (void *) _pointers_, and returns an integer which
|is meant to be a comparison of those pointers according to some total
|ordering.
|Whether it is implemented by comparing addresses or by sending mail to
|the Usenet Oracle and waiting for a reply is not relevant.

I strongly disagree.  Because systems that DO implement ptrcmp by
sending mail to the Oracle are not going to be acceptable implementations
*in practice* of what you require.  You insist for pedagogical reasons
that *all* implementations support your hacks so that you can say your
code is portable to *all* implementations even when in fact your code does
not run acceptably on *all* machines.  Such code is NOT in fact portable.
The portability of such code is pure fiction.  You ask that system
implementors provide you with the implausible so that you can maintain
your fiction.  I disagree.  Rather we should look at those capabilities
that a *very* wide variaty of systems and implementations *can* reasonably
*in reality* support, standardize on the *reality* not the fiction, 
and leave the rest implementation defined.