On 2010-07-27 23:50, Aaron Sherman wrote:
PS: On a really abstract note, requiring that ($a .. $b).reverse be lazy
will put new constraints on the right hand side parameter. Previously, it
didn't have to have a value of its own, it just had to be comparable to
other values. for example:
for $a .. $b -> $c { ... }
In that, we don't include the RHS in the output range explicitly. Instead,
we increment a $a (via .succ) until it's>= $b. If $a were 1 and $b were an
object that "does Int" but just implements the comparison features, and has
no fixed numeric value, then it should still work (e.g. it could be random).
Now that's not possible because we need to use the RHS a the starting point
when .reverse is invoked.
This is exactly why I keep writing posts about Ranges being defunct as
they have been specified now. If we accept the premise that Ranges are
supposed to define a kind of linear membership specification between two
starting points (as in math), it doesn't make sense that the LHS has an
additional constraint (having to provide a .succ method). All we should
require is that both endpoints supports comparison (that they share a
common type with comparison, at least).
To provide expansion to lists, such as for $a .. $b -> $c { ... }, we
should use type coercion semantics, coercing from Range to Sequence and
throw an error if the LHS doesn't support .succ.
Writing ($a .. $b).reverse doesn't make any sense if the result were a
new Range, since Ranges should then only be used for inclusion tests (so
swapping endpoints doesn't have any meaningful interpretation), but
applying .reverse could result in a coercion to Sequence.
Writing for ($a .. $b).reverse -> $c { ...} may then blow up because it
turns out that $b doesn't have a .succ method when coercing to sequence
(where the LHS must have an initial value), just like for $a .. $b -> $c
{ ... } should be able to blow up because the LHS of a Range shouldn't
have to support .succ.
Regards,
Michael.
