Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tektronix.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!mhuxv!mhuxh!mhuxi!mhuxm!mhuxj!houxm!vax135!cornell!uw-beaver!tektronix!robertd
From: robertd@tektronix.UUCP (Bob Dietrich)
Newsgroups: net.lang.pascal
Subject: Re: Comparing pointers in Pascal
Message-ID: <5086@tektronix.UUCP>
Date: Thu, 7-Feb-85 16:44:03 EST
Article-I.D.: tektroni.5086
Posted: Thu Feb  7 16:44:03 1985
Date-Received: Sat, 9-Feb-85 08:10:19 EST
References: <3161@ucla-cs.UUCP> <9300010@uiucdcsb.UUCP>
Organization: Tektronix, Beaverton OR
Lines: 46

>                                 ...  Pascal does not object to the use of
> an assumption that every unique pointer has a corresponding unique scalar
> value, which may be sorted, compared, etc. just like any integer.  Why not
> use "ord (your_pointer)" for the problem above?  Pascal permits the conversion
> of (unique?)* pointers into (unique?)* integers, but tries to prevent direct
> arithmetic on pointers because this is clearly implementation-dependent.
> BTW, ord (pointer) is a freebie (i.e. NOP) in most Pascal compilers.

Application of 'ord' to pointers (or any type other than enumerations,
integers, chars, Boolean, or subranges thereof) is an extension available in
various Pascal implementations, but it is not a standard feature of Pascal.
Berkley Pascal has this extension, although it is not documented.

> * I am not sure, and rather doubt, that Pascal guarantees that pointers and
> integers will always be the same size.  In an implementation with pointers
> larger than integers, the uniqueness assumption of the "ord" solution might
> not hold.  Still, this kind of implementation-dependency seems both less
> likely and less serious.
 
Good point. The Pascal standards explicitly avoid specifying implementation
details to give an implementor freedom to do a good job. An implementation
may have 3 different sizes of pointers (such as for the Intel 286) if it
wants, or define type 'char' to be 16-bits to accomodate extended character
sets (such as for Japanese or the other character sets being standardized).

> I guess that to be completely safe, one would have to use some other
> mechanism to obtain a unique key for each pointer.  These keys could be kept
> with the pointers in the sorted vector (now a vector of records), or could
> be stored in the "pointee" records.  Either way, it would be dead easy to
> keep your sorted vector - with only a small space (one integer) and perhaps
> time penalty (need extra indirection on compares if key stored with pointee).
> Either approach is still O(ln(N)), but is now implementation-independent.

Good! Whenever you run into a roadblock in a language, there's a better than
even chance that you're trying the wrong approach, instead of the language
being deficient. All idioms in German do not translate literally into English,
and vice versa. Each language has its model of the world, which does not make
either wrong. By modifying your design, you may get faster run time, shorter
code, less storage, easier maintenance, better portability, etc.

                                              Bob Dietrich
                                              Tektronix, Inc.
                                              (503) 629-1727
{ucb or dec}vax!tektronix!robertd             uucp address
robertd@tektronix                             csnet address
robertd.tektronix@rand-relay                  arpa address