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 ("<=").
-Martin
