切片索引的惰性如何影响 array/list 的切片? [乐]
How does lazyness of the slice index affects the slicing of an array/list? [RAKU]
当我们使用超出数组边界的索引对数组进行切片时,我们得到的结果是未定义的 (Any)
当我们将相同的切片索引作为惰性列表传递时,我们将得到 array/list 的现有值(并且仅此而已):
my @a = ^5;
say @a[^10]; # (0 1 2 3 4 (Any) (Any) (Any) (Any) (Any))
say @a[lazy ^10]; # (0 1 2 3 4)
很明显切片索引的惰性会影响结果。
为了理解事物的现状并作为概念证明,我编写了简单版本的切片机制:
my @a = ^5;
my @s1 = ^10;
my @s2 = lazy ^10;
sub postcircumfix:<-[ ]-> (@container, @index) {
my $iter = @index.iterator;
gather {
loop {
my $item := $iter.pull-one;
if $item =:= IterationEnd {
last;
}
with @container[$item] {
take @container[$item]
} else {
@index.is-lazy ?? { last } !! take @container[$item];
}
}
}
}
say @a-[@s1]-; # (0 1 2 3 4 (Any) (Any) (Any) (Any) (Any))
say @a-[@s2]-; # (0 1 2 3 4)
但我想知道我的天真算法是否描述了事物在幕后的计算方式!
可以在 array_slice.pm6.
中找到关于幕后工作原理的来源
具体可以在L73看到:
if is-pos-lazy {
# With lazy indices, we truncate at the first one that fails to exists.
my \rest-seq = Seq.new(pos-iter).flatmap: -> Int() $i {
nqp::unless(
$eagerize($i),
last,
$i
)
};
my \todo := nqp::create(List::Reifier);
nqp::bindattr(todo, List::Reifier, '$!reified', eager-indices);
nqp::bindattr(todo, List::Reifier, '$!current-iter', rest-seq.iterator);
nqp::bindattr(todo, List::Reifier, '$!reification-target', eager-indices);
nqp::bindattr(pos-list, List, '$!todo', todo);
}
else {
pos-iter.push-all: target;
}
因此,正如您所猜测的那样,它确实会在列表项不存在后停止。这是毫无疑问的,因为许多惰性列表是无限的,而迭代器不提供一种方法来知道它们是否是无限的(生成器可能是 non-determinative)。
如果你真的想启用这样的东西,你可以,例如,编写你自己的切片器来处理惰性列表,其中元素可能不可用,但你必须注意确保事情只是急切的如果您知道它们是有限的,则进行评估:
multi sub postcircumfix:<-[ ]-> (@a, @b) {
lazy gather {
take @a[$_] for @b;
}
}
my @a = ^5;
my @b = lazy gather {
for ^10 -> $i {
# So we can track when elements are evaluated
say "Generated \@b[$i]";
take $i;
}
};
say "Are we lazy? ", @a-[@b]-;
say "Let's get eager: ", @a-[@b]-.eager;
say "Going beyond indices: ", @a-[@b]-[11]
这个的输出是
Are we lazy? (...)
Generated @b[0]
Generated @b[1]
Generated @b[2]
Generated @b[3]
Generated @b[4]
Generated @b[5]
Generated @b[6]
Generated @b[7]
Generated @b[8]
Generated @b[9]
Let's get eager: (0 1 2 3 4 (Any) (Any) (Any) (Any) (Any))
Going beyond indices: Nil
当我们使用超出数组边界的索引对数组进行切片时,我们得到的结果是未定义的 (Any)
当我们将相同的切片索引作为惰性列表传递时,我们将得到 array/list 的现有值(并且仅此而已):
my @a = ^5;
say @a[^10]; # (0 1 2 3 4 (Any) (Any) (Any) (Any) (Any))
say @a[lazy ^10]; # (0 1 2 3 4)
很明显切片索引的惰性会影响结果。
为了理解事物的现状并作为概念证明,我编写了简单版本的切片机制:
my @a = ^5;
my @s1 = ^10;
my @s2 = lazy ^10;
sub postcircumfix:<-[ ]-> (@container, @index) {
my $iter = @index.iterator;
gather {
loop {
my $item := $iter.pull-one;
if $item =:= IterationEnd {
last;
}
with @container[$item] {
take @container[$item]
} else {
@index.is-lazy ?? { last } !! take @container[$item];
}
}
}
}
say @a-[@s1]-; # (0 1 2 3 4 (Any) (Any) (Any) (Any) (Any))
say @a-[@s2]-; # (0 1 2 3 4)
但我想知道我的天真算法是否描述了事物在幕后的计算方式!
可以在 array_slice.pm6.
中找到关于幕后工作原理的来源具体可以在L73看到:
if is-pos-lazy {
# With lazy indices, we truncate at the first one that fails to exists.
my \rest-seq = Seq.new(pos-iter).flatmap: -> Int() $i {
nqp::unless(
$eagerize($i),
last,
$i
)
};
my \todo := nqp::create(List::Reifier);
nqp::bindattr(todo, List::Reifier, '$!reified', eager-indices);
nqp::bindattr(todo, List::Reifier, '$!current-iter', rest-seq.iterator);
nqp::bindattr(todo, List::Reifier, '$!reification-target', eager-indices);
nqp::bindattr(pos-list, List, '$!todo', todo);
}
else {
pos-iter.push-all: target;
}
因此,正如您所猜测的那样,它确实会在列表项不存在后停止。这是毫无疑问的,因为许多惰性列表是无限的,而迭代器不提供一种方法来知道它们是否是无限的(生成器可能是 non-determinative)。
如果你真的想启用这样的东西,你可以,例如,编写你自己的切片器来处理惰性列表,其中元素可能不可用,但你必须注意确保事情只是急切的如果您知道它们是有限的,则进行评估:
multi sub postcircumfix:<-[ ]-> (@a, @b) {
lazy gather {
take @a[$_] for @b;
}
}
my @a = ^5;
my @b = lazy gather {
for ^10 -> $i {
# So we can track when elements are evaluated
say "Generated \@b[$i]";
take $i;
}
};
say "Are we lazy? ", @a-[@b]-;
say "Let's get eager: ", @a-[@b]-.eager;
say "Going beyond indices: ", @a-[@b]-[11]
这个的输出是
Are we lazy? (...)
Generated @b[0]
Generated @b[1]
Generated @b[2]
Generated @b[3]
Generated @b[4]
Generated @b[5]
Generated @b[6]
Generated @b[7]
Generated @b[8]
Generated @b[9]
Let's get eager: (0 1 2 3 4 (Any) (Any) (Any) (Any) (Any))
Going beyond indices: Nil