The silliness of max()

2010-03-07 Thread Moritz Lenz 
Please take a look at http://rt.perl.org/rt3/Ticket/Display.html?id=73356:

moritz_ rakudo: say max(1..5)
p6eval rakudo c05478: OUTPUT«-Inf␤»
* masak submits rakudobug for max(1..5)

The weird thing is that it is right, according to the current spec. It says

 our multi max( Ordering @by,  *...@values )
 our multi max( Ordering $by,  *...@values )

so the range 1..5 is actually bound to @by of the first candidate,
leaving *...@values empty, and the default value of -Inf for a max() with
no values seems to be quite OK.

Of course this is not what the casual reader suspects.
My proposed solution is to get rid of the sub form of max() entirely.
Any objections?

Cheers,
Moritz
-- 
Moritz Lenz
http://perlgeek.de/ |  http://perl-6.de/ | http://sudokugarden.de/

Re: The silliness of max()

2010-03-07 Thread Jon Lang 
Moritz Lenz wrote:
 Please take a look at http://rt.perl.org/rt3/Ticket/Display.html?id=73356:

 moritz_ rakudo: say max(1..5)
 p6eval rakudo c05478: OUTPUT«-Inf␤»
 * masak submits rakudobug for max(1..5)

 The weird thing is that it is right, according to the current spec. It says

  our multi max( Ordering @by, �...@values )
  our multi max( Ordering $by, �...@values )

 so the range 1..5 is actually bound to @by of the first candidate,
 leaving *...@values empty, and the default value of -Inf for a max() with
 no values seems to be quite OK.

 Of course this is not what the casual reader suspects.
 My proposed solution is to get rid of the sub form of max() entirely.
 Any objections?

Why not just change the by parameter to be named instead of
positional?  Frankly, I don't understand why that isn't already the
case.

-- 
Jonathan Dataweaver Lang

Re: The silliness of max()

2010-03-07 Thread Darren Duncan 

Jon Lang wrote:

Moritz Lenz wrote:

Please take a look at http://rt.perl.org/rt3/Ticket/Display.html?id=73356:

moritz_ rakudo: say max(1..5)
p6eval rakudo c05478: OUTPUT«-Inf␤»
* masak submits rakudobug for max(1..5)

The weird thing is that it is right, according to the current spec. It says

 our multi max( Ordering @by,  *...@values )
 our multi max( Ordering $by,  *...@values )

so the range 1..5 is actually bound to @by of the first candidate,
leaving *...@values empty, and the default value of -Inf for a max() with
no values seems to be quite OK.

Of course this is not what the casual reader suspects.
My proposed solution is to get rid of the sub form of max() entirely.
Any objections?


Why not just change the by parameter to be named instead of
positional?  Frankly, I don't understand why that isn't already the
case.


As Jon Lang says.

Any ordered-concerning function needs to have an optional closure parameter if 
users are going to be able to sort values by an algorithm of their choice, and 
not just a single default one built-in to the type of the values being sorted.


Moreover, by should be a named, optional parameter.

Make @values into an ordinary Positional-doing parameter.

Hmm ... Ordering ... I didn't notice the existence of that type before, and 
will have to look it up.  Just from the above context I assume it is a closure 
having 2 main positional parameters and resulting in an Order value.


-- Darren Duncan