Path: utzoo!utgpu!watmath!att!dptg!rutgers!apple!agate!ucbvax!ARIZONA.EDU!kwalker
From: kwalker@ARIZONA.EDU ("Kenneth Walker")
Newsgroups: comp.lang.icon
Subject: Re: Icon additions
Message-ID: <8909211711.AA08091@megaron.arizona.edu>
Date: 21 Sep 89 17:11:26 GMT
References: <1989Sep21.121032.14168@rpi.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 53

> Date: 21 Sep 89 12:10:32 GMT
> From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
> 
> Pointers could also be used to access non-Icon memory. This would obviously
> be machine and os dependant, but I think is necessary for any language
> on a personal computer.

The word "necessary" is too strong. It is true that the feature
significantly extends the application domain of the language, though.

> Pointers are also usefull for constructing (more efficiently perhaps, or
> more intuitively) tree structures which might have multiple pointers
> in each record (and might have data in each record also).

The pointers are already there in the pointer semantics of Icon data
structures. Your suggestion would just make them explicit. It seems
to me that using them will necessarily make the code to construct
trees more verbose, without adding any power.

I am confused as to what your pointers would be allowed to point to.
You make 3 seemingly conflicting statements:

1) > Pointers could also be used to access non-Icon memory.

2) > The pointers I would implement would be required always to point to a
   > structure.

3) > Pointers are one way to implement pass by reference parameters.

Number 1 could be an "unsafe" pointer type. That is, the programmer
would be responsible for avoiding any kind of memory violation. This
is somewhat un-Iconish, but one makes compromises in language design.
You will probably have to avoid pointing into an Icon structure, because
garbage collection won't know how to relocate the pointer (at least
not without changes to the garbage collector).

Number 2 is no problem; it corresponds to the current pointer semantics
of Icon data structures.

Number 3 requires pointers to variables. While this is no problem
for the garbage collector, there is a problem of dangling pointers
to local variables that no longer exist (this is not a problem if you
only use the pointers for pass-by-reference). Ignoring the problem
would be very un-Iconish! One solution is to allocate local variables
in the heap so they don't go away while something is pointing to them.
For programs that do a lot of procedure calls, this can significantly
increase the number of garbage collections. An other approach would
be to keep track of pointers to local variables and change them
to the null value when the procedure terminates. This would also
be expensive.

   Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
   +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker