On 6/1/05, Deborah Pickett <[EMAIL PROTECTED]> wrote:
> I'm still in the camp of those wanting each operator to know its own identity
> value (perhaps in terms of a trait).  The identity of multiplication (say) is
> always 1, after all, and it doesn't change depending on when you do
> multiplication in your own code.  In mathematical terms, it's a property of
> the operator, not of how it's used.

Also, in mathematical terms, many operators have no identity.  Also,
if we suppose that every operator does have an identity (a silly thing
to do), then we can't just return that.  It doesn't even make sense
for operators like < whose return type is different from its argument
types (but reduce itself doesn't make a lot of sense for such
operators unless they're list-associative).

For something like:

    $ordered = [<] @array;

If @array is empty, is $ordered supposed to be true or false?   It
certainly shouldn't be anything but those two, because < is a boolean
operator.

Coming back to our identities issue, consider:

    $mods = [%] @array;

If @array is empty, what is $mods supposed to be?  There's no
reasonable integer that it could possibly be.

You have to either supply an initial value or refactor your logic not
to allow an empty @array (as in the first case).  If you want it some
other way, there are far too many special cases we have to work with,
some of which are just mathematically impossible.

I think `fail`ing is the best bet.

Luke

Reply via email to