On 6/7/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> Okay, I've made up my mind. The "err" option is not tenable because
> it can cloak real exceptions, and having multiple versions of reduce is
> simply multiplying entities without adding much power. So let's allow
> an optional "identvalue" trait on operators. If it's there, reduce
> can use it. If it's not, reduce returns failure on 0 args. Built-in
> addition will have an identity value of 0, while multiplication will
> have an identity value of 1. String concatenation will have "".
> We can go as far as having -Inf on [<] and +Inf on [>]
< 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
There is a pretty fundamental difference between X,X -> X operators
and X,X -> Y operators wrt reduce. Most languages don't even allow
the latter kind, but I think it would be cool if we did.
I'm not really sure what you mean by "it can mask real exceptions".
If the operator is defined to require 1 or more (or in the case of
nonhomogeneous operators, 2 or more) arguments, then that is a real
exception. "err" just fails to be a realistic fallback mode.
In any case, I'm fairly satisfied with your conclusion (but I wasn't
when I began writing this reply :-). 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.
Binary operators really need two such outputs: one for zero arguments
and one for one argument. The one argument output can be inferred
from the zero argument output (but not vice versa). So, we could
define two properties:
is nullaryvalue(-Inf)
is unaryfunction({ 1 })
And, of course, if nullaryvalue is not defined, then we die (or fail)
when zero arguments are given. unaryfunction will default to {
&op(nullaryvalue, 1) }, or { $_ } if nullaryvalue was not defined,
unless the output type is incompatible with the input type (in which
case we have to die even with one argument). We could also define the
unaryfunction automatically if a default value is given for one of the
arguments of a binary operator.
But this all ceases to be a problem for list-associative operators,
which presumably take a list of arguments rather than just two.
That reminds me, how are <, >, etc. defined anyway? How can we tell
them to be list-associative with each other?
Luke
