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.