buschman@tubsibr.uucp (Andreas Buschmann) (04/10/91)
Hallo,
In the Modula3 report Page 49:
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?
b) is this if and only if v is tracedm or if it is untraced, too?
As I'm writing an interpreter for a subset of Modula3, the answer is
at least interesting for the memory management.
Ah, some additional questions:
- is (a) the reason for DISPOSE beeing an unsafe operation?
- is there a version of the repost in ascii, or dvi format to
filter through dvi2tty, to get a report I can grep in?
- 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.
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 am not so happy with th long name LOCATION, but dont want to
use the abbeviation LOC because of its different meaning in
Algol68 as a local storage allocator in contrast to HEAP, which
is semantically equivalent to NEW in m3.
Tschuess
Andreaskalsow (Bill Kalsow) (04/12/91)
> 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
buschman@tubsibr.uucp (Andreas Buschmann) (04/15/91)
Hi!
I tried to place this in comp.lang.modula3, but it bounced, so I retry
it via the mailing list.
Tschuess
Andreas
/|) Andreas Buschmann
/-|) TU Braunschweig, Germany (West)
^^^^ was
bitnet: buschman%tubsibr@dbsinf6.bitnet
uucp: buschman@tubsibr.uucp
p.s. it bounced at compuserve.com, but I don't know what I have done
wrong. so here it is again:
Hallo,
In the Modula3 report Page 49:
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?
b) is this if and only if v is tracedm or if it is untraced, too?
As I'm writing an interpreter for a subset of Modula3, the answer is
at least interesting for the memory management.
Ah, some additional questions:
- is (a) the reason for DISPOSE beeing an unsafe operation?
- is there a version of the repost in ascii, or dvi format to
filter through dvi2tty, to get a report I can grep in?
- 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.
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 am not so happy with th long name LOCATION, but dont want to
use the abbeviation LOC because of its different meaning in
Algol68 as a local storage allocator in contrast to HEAP, which
is semantically equivalent to NEW in m3.
Tschuess
Andreas