Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ARIZONA.EDU!gudeman
From: gudeman@ARIZONA.EDU ("David Gudeman")
Newsgroups: comp.lang.icon
Subject: Icon additions (was: var params)
Message-ID: <8909142135.AA18591@megaron.arizona.edu>
Date: 14 Sep 89 21:35:37 GMT
References: <7319@rpi.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 38

[I was going to reply directly, but I had doubts about the return
address.  Frank, you should include a return address in your
.signiture file, or maybe add a Reply-To: to your mail header.]

Var params require a new _internal_ data type, but they don't really
require a new user-accessible one.  If you want to go all the way and
add C-style pointers, you have to consider things like what operations
will be allowed.  For example, in C you can add an integer to a
pointer to get a new pointer.  There is no range check because the C
philosophy puts the responsibility for such things on the programmer
and because C models memory as one huge continuous array.  Icon models
memory as a set of independent locations with variable (changing)
sizes, so if you want pointer addition, you have to come up with some
reasonable Iconesque semantics.

Assume that ^expr returns a pointer to the variable produced by expr.
Then {ls := list(10); ptr := ls[3]} creates a list, and makes ptr a
pointer into the list.  Presumably, ptr + 3 returns a pointer to
ls[6].  What does ptr + 9 do?  It would be terribly non-Iconish for it
to produce a random memory location.  I can think of two
possibilities: (1) pointers wrap around in a list, so ptr + 9 produces
a pointer to ls[2], or  (2) ptr + 9 fails, just like ls[3+9] would.

Here's another consideration: what happens after you do a push(ls, x)?
Does ptr still point to ls[3], or does it now point to ls[4]?  All of
this is relatively simple, when you add pointers to table elements
things get complicated...

Multiple dimensioned arrays would be useful, and I can see why you
want them static-sized (to avoid the semantic complexity of APL) , but
I think you are exaggerating the performance penalty of Icon's
variable-sized lists.  If you create a list with the list() function
and never extend it, there is very little difference between access
time of the list and that of a fixed-size array.  In fact, I would be
surprised if you could measure any performance difference by timing
programs.  And the list() only uses about 10 more words of memory than
a fixed-size array would need.  Unless you have hundreds of very small
arrays, this shouldn't be a problem.