Re: vectors are something else

[Daniel Llorens]

On Apr 16, 2013, at 08:19, Mark H Weaver wrote:

> Yes, I did, and generally I strongly prefer column [1], but we have to
> be very careful what changes we make in a stable release series that
> might break compatibility with existing code.  I find this frustrating
> as well, which is one reason why I agree with Andy that shifting focus
> to 2.2 soon would be a good idea.

All right.

> I think you misunderstood me.  I'm not talking about the cost of the
> 'make-shared-array' call itself.  I'm talking about the fact that in
> order to support arrays that might have been created using
> 'make-shared-array', things like 'array-ref' must apply an arbitrary
> affine transformation to the indices in order to compute the offset into
> the linear storage.

Sorry if it sounded that way; the specific mention of make-shared-array puzzled 
me. There are, after all, other functions that imply such a transformation, 
e.g. transpose-array.

> assume anything about what kind of array is passed in.  Such an array
> might have been created by 'make-shared-array', and thus might use an
> arbitrary affine transformation.  If 'vector-ref' can be used on such an
> array, then this procedure would have to fetch the stride and offset and
> do the multiplication each time.  If there's a loop that calls this
> top-level procedure, then the compiler can't do anything with this.

Since vector-ref takes a single index, 'arbitrary affine transformation' is 
b+d*i, all three scalars. In a context where the compiler can't do any 
meaningful optimization, is this going to matter?

At any rate, I accept your point that the indexing cannot be optimized out in 
general.

> This is a weak argument.  You can always make shorter names for them.

I wasn't serious.

> I don't think that arrays should ever be printed as #(2 4).

The obvious alternative is #1(2 4). As of now, these are 100% equivalent.