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;

  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.


Reply via email to