From @masak

<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
semantics better​: use .succ if nothing else is indicated.

From @pmichaud

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
semantics better​: use .succ if nothing else is indicated.

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 C<cmp> to
  determine the direction of the progression.

Rakudo evaluates C< "perl" cmp { ... } > as C<Order​::Decrease>,
therefore it's using the .pred/decreasing progression.

So, one of the following​:
  a) &infix​:<cmp> should produce a different result for Str vs Code
  (if so, what?),
  b) &infix​:<...> should assume .succ if the final value is a Code object,
  c) Rakudo is correct, or
  d) Some other spec clarification or change needs to be made.

Pm

The RT System itself - Status changed from 'new' to 'open'

From @masak

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 C\<cmp> to 
determine the direction of the progression\.

Rakudo evaluates C< "perl" cmp { ... } > as C<Order​::Decrease>,
therefore it's using the .pred/decreasing progression.

Aye. That's clearly to spec.

So, one of the following​:
a) &infix​:<cmp> should produce a different result for Str vs Code
(if so, what?),

&infix​:<cmp> is consistent the way it is, but it's a consistency that
surprises people. (Basically, comparing across incompatible is
impossible.) Adding an exception for Str vs Code feels wrong, and is the
opposite of what &infix​:<cmp> would need to be saner.

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" ... *'

c) Rakudo is correct, or

No. :)

d) Some other spec clarification or change needs to be made.

I'm very satisfied with how the sequence spec has turned out. It's
stable and in some kind of sweet spot. I don't imagine it needs an
overhaul of any kind, actually. But the way this particular case worked
surprised me as a user.

From @pmichaud

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 the case of "perl" ... * ,
&infix​:<...> assumes .succ because the * transforms to Inf, and
"perl" cmp Inf is Order​::Increase. So, it's a special case like *,
but it's a separate special case.

I'm wondering if Code objects just shouldn't participate in
&infix​:<cmp> somehow.

And also if there ought to be something akin to an Order​::None
somewhere.

Either of these might help to more cleanly get the &infix​:<...>
semantics right in this case, as well as potentially solve a
lot of other cmp-related oddities.

Pm

From @geekosaur

On Sat, Mar 23, 2013 at 12​:16 PM, Patrick R. Michaud <pmichaud@​pobox.com>wrote​:

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 sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

From @diakopter

works like niecza did, now

@diakopter - Status changed from 'open' to 'resolved'