Luke Palmer wrote:
< and > still don't make sense as reduce operators. Observe the table: # of args | Return (type) 0 | -Inf 1 | Num (the argument) 2 | bool ... | bool
Let's look at the type of one of the many `reduce' variants in Haskell; foldr1 :: (a -> a -> a) -> [a] -> a This is the Perl6ish; sub reduce( ::Code{( ::(someType), ::(someType) ) returns ::(someType)} $func, Array of ::(someType) ) returns ::(someType); ie, the function $func supplied must take and return arguments of a single type. So you have come to the same conclusion as the FP folk :-). Here I'm using ::(foo) as a coined syntax for a parametric type to the definition. `someType' need not be defined anywhere else, but must be the same within the application of a definition. IMHO we still need to make some movements towards a specification for how this sort of thing is specified... > I just think we have to give > nonhomogeneous operators like < some special treatment. So, from our > somewhat lexical definition of reduce, I don't think an identity input > is what we're looking for. We really want an identity output. When I last looked, in pugs, functions that return "bool" types are currently setup to return one or the other argument when used with reduce; like there is a similar; multi sub reduce( ::{Code( ::(someType) $a, ::(someType) $b ) returns bool} $func, Array of ::(someType) ) returns ::(someType); This gives meaning to operators like [>], which would return the maximum value from a list. Sam.