On Thu, 22 Mar 2012, Carl Mäsak wrote:
> Jonathan Lang (>>), Daniel (>):
> >>    1, 2, 4 ... 100 # same as 1,2,4,8,16,32,64
> >
> > That last one doesn't work on Rakudo :-(
> And it never will. Note that 100 is not a power of 2, and that the goal
> needs to match exactly. This is because smartmatching is used, not some
> other comparison. The sequence will continue to generate numbers until the
> number 100 is generated, which never happens. Rakudo loops forever on this
> one, as per spec.

Hmmm, so it's likely that most times you get a Num rather than an Int or
Rat, those won't stop either?

        1, 7 / 6.0 ... 2
        1, sqrt(2), 2 ... 8

Question: do we support

        1, 2i, -4 ... 256

> If you're wondering why things are factored in this way, it's because
> previous versions of the spec that tried to special-case 100 to work in
> cases like the above, ended up not working out. It turned out that the
> unification of infix:<...> and smartmatching was what did work. It has the
> slight drawback that we have to educate users to write * >= 100 instead of
> 100 in the case of not-exactly-matching goal states. But it's still a net
> win, because this unified semantics works better than anything we had
> before.

Sounds to me like AscendingArithmeticIteratorInclusiveTerminalSmartMatch
could do the same thing as normal SmartMatch except when the LHS is an
IteratorOf{X} and the RHS is an {X}, for X in {Int, Rat, Num} and possibly
other comparable (orderable) types, when ">" would be implied.

Likewise for AscendingArithmeticIteratorExclusiveTerminalSmartMatch (">=")
DescendingArithmeticIteratorInclusiveTerminalSmartMatch ("<") and
DescendingArithmeticIteratorExclusiveTerminalSmartMatch ("<=").


Reply via email to