Path: utzoo!utgpu!watmath!att!dptg!rutgers!apple!gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc
From: vicc@unix.cie.rpi.edu (VICC Project (Rose))
Newsgroups: comp.lang.icon
Subject: Re: Icon additions
Message-ID: <1989Sep21.185607.2120@rpi.edu>
Date: 21 Sep 89 18:56:07 GMT
References: <1989Sep21.121032.14168@rpi.edu> <8909211711.AA08091@megaron.arizona.edu>
Distribution: inet
Organization: Rensselaer Polytechnic Institute, Troy NY
Lines: 103

In article <8909211711.AA08091@megaron.arizona.edu>, kwalker@ARIZONA.EDU ("Kenneth Walker") writes:
> > 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.

Ok, I was too strong here. 

> > 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).

I agree absolutely, I should have clarified things a bit. I think two
types of user pointers are implicated. One should only point to non-Icon
memory and the other for pointing to Icon structures (and this type might
also include some type information). One possibility is that if all the uses
of a non-Icon pointer are easy to enumerate (including possible calls to
malloc for non-Icon memory on the heap) Then one could set up a more
bomb proof pointer structure.

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

My intention is to follow Icon as closely as possible here to ease the work
of the garbage collector.

> 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.

This is one I didn't think about too much. Of course this is one advantage
of airing ones ideas in such a forum (of course when I sat down to actually
do the implementation I hope I would have seen this).

Here is an idea that might work:

   When a pointer to a local variable (static variables are fine) is generated,
we move the variable into the heap and replace the local variable with a
construct similar to a trapped variable. Thus if the pointer is left hanging,
the pointer is actually pointing to something in the heap which is then
accesible to the garbage collector and remains after the procedure returns.
I think this would provide protection without too much heap overhead. If the
use of a pointer to a local variable was intentional, and the procedure was
not re-entrant (recursive or otherwise), then a static variable could be used
to avoid the heap allocation.


One advantage that I do see to Icon pointers is that with care, you can never
end up with a dangling pointer. In Pascal or C it is easy to allocate
memory for a structure, set a pointer to it, copy that pointer, release the
memory and still have a pointer to the memory. In Icon, to deallocate
memory pointed to by a pointer, all we need do is set the variable to &null
(or any non-pointer variable). If all pointers to a structure are removed
in this way, the garbage collector will free the memory when called.

One thing in reference to non-Icon pointers is that I think most of the
time one would need them (other than for I/O type activities which can
easily be implemented in Icon so that pointers are not needed for them)
is that Icon can allocate the memory and then when the pointer need be
passed to some C or assembly function, the pointer can just be adjusted to
point to the space in the block. If a block is needed which can't be
moved, one could use malloc or modify the garbage collector in some way.


Frank Filz
Center For Integrated Electronics
Rensselaer Polytechnic Institute
vicc@unix.cie.rpi.edu