@a[1..*] adds trailing undef value

[p6rt]

Migrated from rt.perl.org#64566 (status was 'resolved')

Searchable as RT64566$

[p6rt]

From @moritz

23​:55 <@​moritz_> rakudo​: my @​a = 1..4; say @​a[1..*].perl
23​:56 < p6eval> rakudo 6b9755​: OUTPUT«[2, 3, 4, undef]␤»

It should just be [2, 3, 4].

Cheers,
Moritz

[p6rt]

From @kyleha

This is an automatically generated mail to inform you that tests are now available in b/t/spec/S02-builtin_data_types/whatever.t

[p6rt]

The RT System itself - Status changed from 'new' to 'open'

[p6rt]

From @moritz

On Wed Apr 08 14​:59​:19 2009, moritz wrote​:

23​:55 <@​moritz_> rakudo​: my @​a = 1..4; say @​a[1..*].perl
23​:56 < p6eval> rakudo 6b9755​: OUTPUT«[2, 3, 4, undef]␤»

It should just be [2, 3, 4].

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.

Cheers,
Moritz

[p6rt]

From frettled@gmail.com

On Wed, Aug 19, 2009 at 1​:54 PM, Moritz Lenz via RT <
perl6-bugs-followup@​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.

I like it the way S09 says it.

But there is a problem with sparse arrays, isn't there?

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.)

For arrays, it appears that using end is more relevant​:

our Any method end (@​array​: ) is export

Returns the final subscript of the first dimension; for a one-dimensional
array this simply the index of the final element. For fixed dimensions this
is the declared maximum subscript. For non-fixed dimensions (undeclared or
explicitly declared with *), the index of the actual last element is used.

Does that seem usable to y'all?
--
Jan

[p6rt]

From dataweaver@gmail.com

On Wed, Aug 19, 2009 at 5​:37 AM, Jan Ingvoldstad<frettled@​gmail.com> wrote​:

On Wed, Aug 19, 2009 at 1​:54 PM, Moritz Lenz via RT <
perl6-bugs-followup@​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

[p6rt]

From @pmichaud

On Wed, Aug 19, 2009 at 04​:54​:10AM -0700, Moritz Lenz via RT wrote​:

On Wed Apr 08 14​:59​:19 2009, moritz wrote​:

23​:55 <@​moritz_> rakudo​: my @​a = 1..4; say @​a[1..*].perl
23​:56 < p6eval> rakudo 6b9755​: OUTPUT«[2, 3, 4, undef]␤»

It should just be [2, 3, 4].

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.

The short answer is that 1..* isn't a WhateverCode object, it's a Range
with a Whatever endpoint. (Rakudo currently gets this wrong, yes.)
So postcircumfix​:<[ ]> then changes its dispatch based on having a
Range argument.

Pm

[p6rt]

From sohtil@gmail.com

Current Rakudo considers 1..* a Range object​:

$ ./perl6

say (1..*).WHAT
Range()

However, @​a[1..*] does not terminate​:

$ ./perl6

my @​a = 1..4; say @​a[1..*].perl

... no response

This is Rakudo Perl 6, version 2010.07-115-g0839993 built on parrot
2.6.0 r48341

[p6rt]

From @masak

<TimToady> rakudo​: my @​a = 1,2,3,4; say @​a[1..*]
<p6eval> rakudo 82c9e9​: OUTPUT«(timeout)»
<TimToady> rakudobug
* masak submits

[p6rt]

From sohtil@gmail.com

There is also an older ticket about .[1..*]​: #​64566

[p6rt]

The RT System itself - Status changed from 'new' to 'open'

[p6rt]

From sohtil@gmail.com

See also the recent report about .[1..*] in #​77422.

[p6rt]

From @Timbus

After a day of thinking heavily, drinking heavily and asking IRC folk,
the only solution seems to be to make Range store the Whatever instead
of trying to convert it to Inf/-Inf/etc during construction. Then
postcircumfix[] can check the given Range's $min and $max for Whatever
and act accordingly.

This would require a bit of code rewiring in Range though, which makes
me wonder if it's worth it. Maybe a special parse rule could catch this
instead?

[p6rt]

From @pmichaud

Now fixed in nom branch​:

  pmichaud@​kiwi​:~/nom$ ./perl6
  > my @​a = 1..4; say @​a[1..*].perl
  (2, 3, 4)

Since a test is already recorded in whatever.t, I'm closing the ticket.
Thanks!

Pm

[p6rt]

@pmichaud - Status changed from 'open' to 'resolved'

[p6rt]

From @moritz

Test passes on latest rakudo/nom, closing ticket.