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.Thread Previous | Thread Next