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.
