Path: utzoo!utgpu!watmath!att!dptg!rutgers!ucsd!ucbvax!naucse.UUCP!sbw
From: sbw@naucse.UUCP (Steve Wampler)
Newsgroups: comp.lang.icon
Subject: Re: Icon additions
Message-ID: <8909211737.AA26397@naucse>
Date: 21 Sep 89 17:37:37 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 60

On Sep 21 at  6:33, VICC Project (Rose) writes:
} 
} 
} 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 most successeful pc programs are those which
} directly use the machines resources. They may or may not do so in a
} structured way. I will agree that this reason for pointers is a VERY
} touchy subject.

I can see this use, though perhaps there is some other way.
 
} 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).

I guess I don't see this one.  That's already easy to do.  Perhaps it's
more intuitive to one who things in pointers, but you're really using
pointers to represent hierarchies.

} The pointers I would implement would be required always to point to a
} structure. This would simplify garbage collection in that there would be
} a block (pointed to by a variable = accessible to garbage collector) which
} contains a pointer to a block and the type of that block. I understand that
} setting things up for the garbage collector is most important.

If you do this, then...

} Pointers are one way to implement pass by reference parameters. Basically, I

you're being redundant.  Given your constraint above, you already have it in
Icon.  Try the following program:

	procedure main()
   	local a
   	   call(a := [])
   	   every write(!a)
	end

	procedure call(x)
   	   every put(x,1 to 10)
	end

You must mean to have internal pointers as being different than pointers at
the source level?

Pointers are not the only way to do this, though they are perhaps the
simplest to implement.  I do see a lot of redundancy showing up, however,
given that structures provide pointer 'functionality' already.  It only
seems a gain in having pass by reference to simple data types.  A more
'Icon-ish' solution would be to extend the co-expression mechanism to
do it for you - i.e. have co-expressions exist in the environment of
their creation, rather than in a copy of that environment (providing
a scheme for isolating the environment if needed).  That gives you
more flexibility than simple pointers.  Of course, it also requires
some substantial (and potentially costly) changes to the implementation.

-- 
	Steve Wampler
	{....!arizona!naucse!sbw}