Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uwm.edu!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 (was: var params)
Message-ID: <7331@rpi.edu>
Date: 15 Sep 89 02:48:58 GMT
References: <7319@rpi.edu> <8909142135.AA18591@megaron.arizona.edu>
Sender: usenet@rpi.edu
Distribution: inet
Lines: 80

In article <8909142135.AA18591@megaron.arizona.edu>, gudeman@ARIZONA.EDU ("David Gudeman") writes:
> [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.]

I wasn't thinking about that. We have a central news server here which actually
submits the articles. One of the problems is you can not cancel an article.

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

If I implemented a user-accessible pointer type I would implement it in a more
pascalish way. You can get a pointer to a variable, copy a pointer, or get
a pointer to newly allocated space. I think anything more (such as c type
operations) would stretch Icon's structure a bit too far (at least for my
tastes)
> 
> 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...

As far as I can see, it would have to now point to ls[4], it would take
a lot of work to change all of the pointers that might exist to ls[3].
This of course is one place that pointers will get messy with Icon even if
operations are not defined on pointers.

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

I see that for a single dimensioned array, but what about a multi-dimensioned
array with lists, is not that a list of lists, in which case you have that
extra 10 words of overhead for each sub list? Also you have the time of an
extra list lookup as opposed to a multiplication. I think you are right though,
now that I think about it the speed improvement probably wont be much, but
I can see some space improvement by avoiding the list of lists. Of course
the programmer could also do the multiplication himself.

The other thing I hope to be able to do is to allow arbitrary lower bounds
which will improve the readability of some types of algorithms. Another
advantage of the array would be that copy would copy all the elements, not
just the first dimension.

Another reason to play with arrays is that I believe they will be a relatively
simple implementation which should be a good practice start. Pointers on the
other hand obviously have many ramifications which must be examined.

One other question, is it correct that to add an operator one will have to
alter ICONT?

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