On Apr 15, 2013, at 14:28, Daniel Hartwig wrote:
> Though such an array is potentially still a vector according to the simple
> explanation in the manual. So this requires introducing a more
> complicated discussion of when is an array a vector.
Not really. One just needs to say 'these functions produce vectors. Everything
else doesn't'.
> And a lot of the
> uses for treating some arrays as vectors will be lost with this, as it
> quite restrictive on the layout of the source data.
True. One could use arrays though.
> Given the semantic complications and lesser utility, it may as well be
> that no vectors are arrays and reject all.
No disagreement here.
> In this case, ‘vector?’ still must answer #f as the offset indexing
> makes the object not a vector. Right?
Well... it's really the same argument of 'it is an error'. We can do whatever.
> Most non-vector objects passed to ‘vector-ref’ will throw an error,
> except for offset arrays. Since the result is unspecified aka “it is
> an error”, it doesnt have to be correct (ie. include lbnd).
Wrong is wrong. Besides, people tend to rely on unspecified behavior. It's the
worst we could do.
> Is it
> really much faster to do one or the other:
>
> if lbnd != 0: error
> index = …
>
> vs:
>
> index = lbnd + ...
The second should actually be just
index = ...
You do this by having the base index point to the element at index 0 and not to
the first element. This is a mistake all through the Guile array code.
A branch would certainly be slower. However, if the array implementation was
exposed to the compiler, the lbnd!=0 check could be hoisted out of any array
loop. So both would end up being identical in that case.
I prefer the second option. But if it comes to you and I having to agree, I'd
be ok with the first.
I'm sending a poll to get some more reactions.
Regards
Daniel
