From @masak

<masak> r​: say [max] <2 11>
<p6eval> rakudo 4373f0​: OUTPUT«2␤»
<masak> n​: say [max] <2 11>
<p6eval> niecza v15-6-gefda208​: OUTPUT«11␤»
<masak> inneresting.
* masak submits rakudobug
<brrt> max compares them as strings, seems to be the explanation
<masak> brrt​: they are strings.
<masak> brrt​: actually, they are weird Str/Int hybrids, and the Int
aspect should probably win when sorting.
<brrt> i would hope so

From @usev6

today there was another discussion about this on #perl6​:

<gtodd> m​: say <1 2 3 4 5 10>.max
<camelia> rakudo-moar 6edc31​: OUTPUT«5␤»
<ab5tract> m​: say (1,2,3,4,5,10).max
<camelia> rakudo-moar 6edc31​: OUTPUT«10␤»
<bartolin> that's also RT #​112250
<gtodd> bartolin​: ok thanks ... it's like the <> form is accidentally making lists out of the elements
<gtodd> but I'm splittling a line and pushing the number into an array and they are still tricking max into seeing them as strings
<gtodd> .max
<lue> gtodd​: the point of < > is to create an array of strings, e.g. <one two three> instead of ("one", "two", "three")
<lue> stuff like [+] <1 2 3> works simply because infix​:<+> tries to coerce its arguments to numbers if they aren't already.
<bartolin> lue​: so you would say its correct [max] sorts <2 11> lexicographically?
<bartolin> m​: say [max] <a z c>
<camelia> rakudo-moar 6edc31​: OUTPUT«z␤»
<bartolin> m​: say [max] <2 11>
<camelia> rakudo-moar 6edc31​: OUTPUT«2␤»
<lizmat> yes, because in that context, 2 and 11 are Str
<lizmat> m​: say [max] (2,11)
<camelia> rakudo-moar 6edc31​: OUTPUT«11␤»
<ab5tract> m​: say [max] (2.Str,11.Str)
<camelia> rakudo-moar 6edc31​: OUTPUT«2␤»
<lizmat> m​: say [max] ("2","11") # same thing
<camelia> rakudo-moar 6edc31​: OUTPUT«2␤»
<lue> Unless <2 11> is supposed to be a list of IntStrs, and unless the Int part of IntStr is supposed to win when either part would do,
I think [max] <2 11> -> 2 is right.
<colomon> m​: say <2 11>.max(+*)
<camelia> rakudo-moar 6edc31​: OUTPUT«11␤»
<colomon> lue​: good point
<colomon> n​: say <2 11>.max
<camelia> niecza v24-109-g48a8de3​: OUTPUT«11␤»
<colomon> n​: say <2 11>[0].WHAT
<camelia> niecza v24-109-g48a8de3​: OUTPUT«(IntStr)␤»
<colomon> <2 11> is indeed supposed to be IntStrs, unless someone has changed that part of the spec again
<bartolin> and IntStr is probably NYI for rakudo ...
<bartolin> m​: say <2 11>[0].WHAT
<camelia> rakudo-moar 6edc31​: OUTPUT«(Str)␤»
<colomon> so I think lue is right that max is supposed to do what bartolin thinks it should
<lue> r​: say IntStr
<camelia> rakudo-{parrot,moar} 6edc31​: OUTPUT«===SORRY!=== Error while compiling /tmp/tmpfile␤Undeclared name​:␤ IntStr used at line 1␤␤»

Maybe the subject should be changed from "[BUG]" to "[TODO]"?

@usev6 - Status changed from 'new' to 'open'

From @coke

On Thu Dec 04 15​:07​:30 2014, bartolin@​gmx.de wrote​:

today there was another discussion about this on #perl6​:

<gtodd> m​: say <1 2 3 4 5 10>.max
<camelia> rakudo-moar 6edc31​: OUTPUT«5␤»
<ab5tract> m​: say (1,2,3,4,5,10).max
<camelia> rakudo-moar 6edc31​: OUTPUT«10␤»
<bartolin> that's also RT #​112250
<gtodd> bartolin​: ok thanks ... it's like the <> form is accidentally
making lists out of the elements
<gtodd> but I'm splittling a line and pushing the number into an
array and they are still tricking max into seeing them as strings
<gtodd> .max
<lue> gtodd​: the point of < > is to create an array of strings, e.g.
<one two three> instead of ("one", "two", "three")
<lue> stuff like [+] <1 2 3> works simply because infix​:<+> tries to
coerce its arguments to numbers if they aren't already.
<bartolin> lue​: so you would say its correct [max] sorts <2 11>
lexicographically?
<bartolin> m​: say [max] <a z c>
<camelia> rakudo-moar 6edc31​: OUTPUT«z␤»
<bartolin> m​: say [max] <2 11>
<camelia> rakudo-moar 6edc31​: OUTPUT«2␤»
<lizmat> yes, because in that context, 2 and 11 are Str
<lizmat> m​: say [max] (2,11)
<camelia> rakudo-moar 6edc31​: OUTPUT«11␤»
<ab5tract> m​: say [max] (2.Str,11.Str)
<camelia> rakudo-moar 6edc31​: OUTPUT«2␤»
<lizmat> m​: say [max] ("2","11") # same thing
<camelia> rakudo-moar 6edc31​: OUTPUT«2␤»
<lue> Unless <2 11> is supposed to be a list of IntStrs, and unless
the Int part of IntStr is supposed to win when either part would do,
I think [max] <2 11> -> 2 is right.
<colomon> m​: say <2 11>.max(+*)
<camelia> rakudo-moar 6edc31​: OUTPUT«11␤»
<colomon> lue​: good point
<colomon> n​: say <2 11>.max
<camelia> niecza v24-109-g48a8de3​: OUTPUT«11␤»
<colomon> n​: say <2 11>[0].WHAT
<camelia> niecza v24-109-g48a8de3​: OUTPUT«(IntStr)␤»
<colomon> <2 11> is indeed supposed to be IntStrs, unless someone has
changed that part of the spec again
<bartolin> and IntStr is probably NYI for rakudo ...
<bartolin> m​: say <2 11>[0].WHAT
<camelia> rakudo-moar 6edc31​: OUTPUT«(Str)␤»
<colomon> so I think lue is right that max is supposed to do what
bartolin thinks it should
<lue> r​: say IntStr
<camelia> rakudo-{parrot,moar} 6edc31​: OUTPUT«===SORRY!=== Error while
compiling /tmp/tmpfile␤Undeclared name​:␤ IntStr used at line 1␤␤»

Maybe the subject should be changed from "[BUG]" to "[TODO]"?

IntStr now works - closable with tests.

14​:40 < [Coke]> m​: say <1 2 3 4 5 10>.max
14​:40 <+camelia> rakudo-moar 25fed4​: OUTPUT«10␤»
14​:41 < [Coke]> m​: <1 2 3>[2].WHAT.say
14​:41 <+camelia> rakudo-moar 25fed4​: OUTPUT«(IntStr)␤»

--
Will "Coke" Coleda

From @usev6

I added two tests for [max] and .max with commit Raku/roast@76adbe5915

IntStr is tested in S02-literals/allomorphic.t

I'm closing this ticket as 'resolved'.

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