Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.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
Message-ID: <1989Sep21.121032.14168@rpi.edu>
Date: 21 Sep 89 12:10:32 GMT
References: <8909202335.AA19395@megaron.arizona.edu>
Distribution: inet
Organization: Rensselaer Polytechnic Institute, Troy NY
Lines: 92

In article <8909202335.AA19395@megaron.arizona.edu>, nevin1@ihlpb.UUCP (Nevin J Liber +1 312 979 4751) writes:
> >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.
> 
> My question to you is:  what do you wish to be able to do with
> pointers in Icon?  Pointers are needed in languages like Pascal, C,
> etc. to implement entities such as linked lists and hash tables.  But
> these are already built into Icon!

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.

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

> Also, trying to implement
> user-accessible pointers in conjunction with garbage collection is far
>from trivial.

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.

> I just can't see what new types of *implementation-independent*
> (I know that there basically only one implementation of Icon right now,
> but language design should not be restricted to one implementation)
> applications that I cannot now write in Icon solely because I don't have
> pointers.  What power would pointers give me?

Pointers are one way to implement pass by reference parameters. Basically, I
see an internal pointer type comming out to implement pass by reference
parameters without changing syntax in a way which would break existing
programs (a very important consideration in any change to Icon). Once these
pointers exist, it would be easy to make that pointer structure available
to the programmer.

> >The other thing I hope to be able to do is to allow arbitrary lower bounds
> >[on arrays,] which will improve the readability of some types of algorithms.
> 
> IMHO, this would not be very Icon-ish.  First off, negative indices
> already are defined in Icon; they allow you to work from the end
> of a string, list, etc.  instead of the beginning; with arbituary
> lower bounds on arrays, this wouldn't work (there are ways to kludge it
> in, but code that would take advantage of it would look very messy).

I don't see how this would be non-Iconish, also note that the suggested
project in the Icon implementation book mentioned lower bounds other than
1. Tables do not follow this indexing. I see arrays as allowing more
efficient means of storing data which most logically should be organized
in a multi-dimensioned manner by scalar indices. Sparse arrays should be
implemented with tables.

> Secondly:  for the current data types, to generate over them in reverse
> order the construct "every element := dataType[*dataType to 1 by -1]" works; 
> this would not hold true for non-0 lower-bounded arrays.

Not for tables. (note also that the "Iconish" way would be a lower bound
of 1 not 0 :-)

> Thirdly:  how does one pass an array to a procedure?  A procedure would
> need some way of determining the lower bound of an array passed to it

The array block will contain the ranges for each dimension. I think image()
would be one way to retrieve these. A record type access to them might also
work. At the worst case, an internal function may be used. Other than that,
arrays will be passed like all other structures (ie effectively a pointer
is passed)

One other item I was thinking of to go with arrays is a range data type
with a constuctor like .. (ie A[1..3]). This could allow reverse order
specification (which could even be used by the interpreter). I see that
this range data type would be converted to a subrange (1:3) if used
anywheres where a subrange is allowed (lists and strings). A[1..3]
might construct a list even.






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