On Wed, Aug 19, 2009 at 5:37 AM, Jan Ingvoldstad<frett...@gmail.com> wrote:
> On Wed, Aug 19, 2009 at 1:54 PM, Moritz Lenz via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
>>
>> Since the discussion came up on #perl6 if this is really the expected
>> behaviour, S09 says:
>>
>> As the end-point of a range, a lone "whatever" means "to the maximum
>> specified index" (if fixed indices were defined):
>>
>> say @calendar[5..*]; # Same as: say @calendar[5..11]
>> say @calendar{Jun..*}; # Same as: say @calendar{Jun..Dec}
>>
>> or "to the largest allocated index" (if there are no fixed indices):
>>
>> say @data[1..*]; # Same as: say @results[1..5]
>>
>>
>> It doesn't mention how the postcifcumfix:<[ ]> is supposed to introspect
>> those to find out if the WhateverCode object constructed by 1..* needs
>> to receive self.elems or self.elems-1 as an argument.
>>
>> Which is why I CC: p6l to get some ideas or clarification, and if we
>> want to maintain this DWIMmy but not very consistent behaviour.
Given that it's relatively easy to say "1..^*", I wouldn't mind
standardizing this so that '*' always refers to the element just past
the last one, at least when dealing with the standard index. That
said, when dealing with a custom index, there generally isn't an
easily identified "one element past the end" position that can be
referenced; so I'd be inclined to standardize everything there such
that '*' always refers to the last element. And if we're going to do
that, why not do the same for standard indexing? e.g., '*' is always
the last element; '*-1' is always one in from the last element; etc.
> I like it the way S09 says it.
>
> But there is a problem with sparse arrays, isn't there?
There shouldn't be, because there shouldn't be sparse arrays - at
least, not in standard indexing. One of the reasons for the
introduction of custom indices was the idea that "sparseness" would
take place in them, so that the standard index could be relied upon yo
provide ordinal access to the elements: @a[0] should _always_ be the
first element; @a[1] should always be the second element, and so on.
And you should always be able to reach the next item by adding one to
the current item's index. That is, the standard index will always be
'0..^$number-of-items'.
If we're not going to follow this rule, then I see no reason why we
shouldn't just have the "custom indexing" mechanism _replace_ standard
indexing, rather than exist side by side with it. If the standard
index can't be depended on for standardized behavior, it's useless.
That said, a case could be made that the custom indexing model is too
strict as written: it forces you to pre-establish a one-to-one
relationship between the standard and custom indices, which largely
negates its usefulness in implementing the concept of sparse arrays.
I recommend loosening up the restrictions on custom indexing and
putting a note in the spec to clarify the intended purpose and
features of the standard index.
> S32/Containers (S32-array) says this about elems:
>
>> our Int method elems (@array: ) is export
>>
>> Returns the length of the array counted in elements. (Sparse array types
>> should return the actual number of elements, not the distance between the
>> maximum and minimum elements.)
This is exactly what the division between standard and custom indexing
was supposed to avoid. When using standard indexing, the distance
between the minimum (i.e., [0]) and maximum (i.e., [*-1]) elements
should always be the actual number of elements; so no such special
note should be needed.
--
Jonathan "Dataweaver" Lang
