On Fri, Mar 22, 2013 at 03:31:57PM -0700, Carl Mäsak wrote:
masak rn: say .[*-1] given perl ... { 3 == ++state $ }
p6eval rakudo 221a95: OUTPUT«perj»
p6eval ..niecza v24-35-g5c06e28: OUTPUT«pern»
* masak submits rakudobug
I'm just assuming this isn't spec'd behavior. I like Niecza's
Pm ():
S03 has:
For functions deduced when there is only one value on the left,
the final value is used to determine whether *.succ or *.pred is
more appropriate. The two values are compared with Ccmp to
determine the direction of the progression.
Rakudo evaluates C
On Sat, Mar 23, 2013 at 07:50:55AM -0700, Carl Mäsak via RT wrote:
b) infix:... should assume .succ if the final value is a Code
object,
This alternative makes sense to me. It's similar to how infix:...
assumes .succ in this case: 'perl ... *'
Similar, yes, but also a little off. In
On Sat, Mar 23, 2013 at 12:16 PM, Patrick R. Michaud pmich...@pobox.comwrote:
And also if there ought to be something akin to an Order::None
somewhere.
Order::NonComparable, possibly which behaves as a (delayed?) exception of
some kind?
--
brandon s allbery kf8nh
# New Ticket Created by Ira Byerly
# Please include the string: [perl #117317]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=117317
Hello,
Oddly, this is exactly the same symptom that was reported and resolved
