Some thoughts... David Rush (21 Nov 2001 19:26 UTC)
Bad things Re: Some thoughts... Jussi Piitulainen (21 Nov 2001 20:25 UTC)
Re: Bad things Re: Some thoughts... David Rush (22 Nov 2001 16:10 UTC)
Access time of elements Re: Bad things [] Jussi Piitulainen (27 Nov 2001 10:59 UTC)
Re: Access time of elements Re: Bad things [] Per Bothner (27 Nov 2001 17:10 UTC)
Re: Access time of elements Re: Bad things [] David Rush (27 Nov 2001 17:25 UTC)
Re: Access time of elements Re: Bad things [] Per Bothner (27 Nov 2001 17:55 UTC)
Re: Access time of elements Re: Bad things [] David Rush (27 Nov 2001 21:19 UTC)
Re: Access time of elements Re: Bad things [] Jussi Piitulainen (28 Nov 2001 15:40 UTC)
Re: Access time of elements Re: Bad things [] Jussi Piitulainen (28 Nov 2001 16:20 UTC)
Re: Access time of elements Re: Bad things [] Noel Welsh (28 Nov 2001 10:55 UTC)
Re: Access time of elements Re: Bad things [] Jussi Piitulainen (28 Nov 2001 17:21 UTC)

Re: Access time of elements Re: Bad things [] Jussi Piitulainen 28 Nov 2001 17:21 UTC

Noel Welsh writes:

[on (array-set! arr whole-index-in-one-argument o) being
the more natural interface]

>                           [ ] there needs to be an
> array/function duality of the same kind we have for
> lists. I.e. you need to be able to pull apart arrays
> and use those parts to pull apart other arrays.

Yes, I'd like to see something like that. That's why I
wanted to represent shapes as arrays. Note that one can
always get there if one is willing to use appropriate
tools explicitly. For example, if shapes are made their
own type, I just write me shape->array and array->shape
and pay as I go.

> So I advocate using arrays as indices to arrays (NB:
> there is no separate index object in this proposal).

But sure is - the arrays. Ok, no separate type. That's
good. - It's my proposal where there is no index object,
and there lists tend to pop up when the number of indices
is not known at the time of writing (procedure calls are
tied to lists through variary stuff and apply).

[snip example until]
>   The current proposal:
>
>   (let ((location (array-ref hotest 0 0))
>         (time (array-ref hotest 0 1)))
>      (array-ref temparatures location time))
>
>   My proposal:
>
>   (array-ref temparatures (array-ref hotest #(0)))

'#(0), though at the moment it would really have to be
(array (shape 0 1) 0) or perhaps (array-index 0).
Vectors are not in yet.

> The first array ref returns the array-slice hotest[0:]
> The second uses that array slice to index into the
> temparatures array.

The outer array-ref illustrates why you want to be able
to use arrays as index objects.

I don't see why you should use array-ref to create the
slice, though. Just call it something else, say
(array-slice a (mumble 0)), or even (array-row a 0), and
leave array-ref for single element access.

Three questions: what should be available, what should be
thought primitive, what should a particular primitive be.

> In my opinion this is much cleaner code.

I don't see this. It is shorter but harder to understand.
It is good to be able to use the row as a single thing.
--
Jussi