Re: alternative array syntax

[Per Bothner <per at bothner dot com>]

Bruce Lewis wrote:
> I like it.  Extending expression evaluation to allow array values in the
> first position seems like a natural extension to me.

Right, but consider this:

If we use Scheme function application syntax to index primitive Java
arrays, then one should probably also do the same for Scheme arrays:
i.e. classes that implement gnu.lists.Array.

Now consider that gnu.lists.SimpleVector implments gnu.lists.Array
(since a vector is a rank-1 array), and that the classes used for
Scheme strings and vectors (FString and FVector respectively)
extend SimpleVector, as do the other uniform vector types.

So the logical consequence is that we should allow function call
syntax for string and vector indexing as well.  E.g.

(vector-ref vec i) == (vec i)
(string-set! str i val) == (set! (str i) val)

Now I happen to think one *should* view arrays and vectors as functions
and use function-call-syntax, so I'm comfortable with this.  But it's
not in the Scheme mainline, which doesn't seem to believe in inheritance
or an overloaded collections framework.  The practical downside (in
addition to increasing the temptation to write non-portabl code) is that
some errors may be caught later, and some code written without type
declarations will be harder to optimize.

The proposal is to generalize function application to allow other
"fuctions":
* A Type or class: Usually creates a new instance, but in some cases
could returned a shared instance.
* Specifically array types: use the length: keyword to specify the array
length and use other values to specify initial values.
* A Java primitive array: array indexing.
* A object that implements gnu.lists.Array (which includes strings
and vectors): array indexing.

Other ideas:
* An AffineTranform: Return the transformed object.
* A "style": Return a styled object.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/