Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!src.dec.com!kalsow
From: kalsow (Bill Kalsow)
Newsgroups: comp.lang.modula3
Subject: Re: DISPOSE statement  and other pointer related question
Message-ID: <9104112036.AA00981@jumbo.pa.dec.com>
Date: 11 Apr 91 20:36:37 GMT
Lines: 65
In-Reply-To: Message of 10 Apr 91 15:23:10 GMT
    from buschman@tubsibr.uucp (Andreas Buschmann)
    <1991Apr10.152310.28913@tubsibr.uucp>
To: m3
Cc: buschman@tubsibr.uucp (Andreas Buschmann), kalsow

>    A DISPOSE Statement has the form:
>  
>  	DISPOSE (v)
>  
>    where v is a writable designator with a fixed or object reference
>    type. 
>    If v is untraced, the statement frees the storage for v's referent
>    and sets v to NIL.  
>    Freeing storage to which active references remain is an unchecked
>    runtime error.  							(a)
>    If v is traced, the statement is equivalent to v := NIL. 
>    If v is NIL, the statement is a no-op. 				(b)
>  
>  Two questions rise here:
>    a) is this an unchecked runtime error if and only if v is untraced,
>       or is it one if v is traced, too?

The statement labeled (a) above is true, it doesn't depend on v. 
The statement doesn't have much to do with DISPOSE, except that DISPOSE 
is the only language defined way to free storage.  The following 
statement says that if v is traced, "DISPOSE (v)" is equivalent to 
"v := NIL".  Since that assignment doesn't free storage, it cannot 
cause an unchecked runtime error.

>    b) is this if and only if v is traced or if it is untraced, too?

The statement (b) is true for both traced and untraced v's.

>    -  is (a) the reason for DISPOSE beeing an unsafe operation?

Yes, anything that can cause unchecked runtime errors is unsafe.

>    -  is there a version of the repost in ascii, or dvi format to
>       filter through dvi2tty, to get a report I can grep in?

No.

>    -  I have't found a save way (without using unsafe features) getting
>       a checked reference onto a variable, or on a part of a structure
>       or array. I wan't the same effect as in ALGOL68 writing:
>  
>  	INT ii := 20;
>  	REF INT iii := ii;
>  	write (iii)
>  
>       which doesn't make much at the first glance, but is necessary for
>       some iterative rewritings of recursive algorithms for linked list
>       inserting.

Right,  Algol68 REFs are not the same as Modula-3 REFs.

>       For my interpreter I created a procedureal operator LOCATION:
>  
>  	LOCATION (VAR x: Any) : REF Any
>  
>       How is this supposed to go in the new standard?

I don't understand.  Are you proposing that LOCATION be added to the
language?  If so, you should post a full explanation of the proposal
and its impact.  For instance, it appears to me that LOCATION would
place great constraints on the possible allocator/collector implementations.
Since I can use LOCATION to create a REF to an arbirary field in an
arbitrary record, the collector cannot assume that type tags are near by?

  - Bill Kalsow