in reply to Re^6: List::Util::sum() and empty lists... (obvious)
in thread List::Util::sum() and empty lists...

If I call my bank and they tell me "You have no money left" ( which is a perfectly plausible reply ) I know i have £0 credit because I don't have trouble understanding the value of zero/null/undef/nothing, they're all different words representing the same thing, mathematically or otherwise.

Most DBI::* methods return 0 (0E0) on success, doesn't mean they're returing false? Tie::Cacher::fetch() returns undef even on success, doesn't mean it is indicating a failure. Either we have a radical overhaul demanding that there is mathematical consistency all around or we just go on using these funny quirks that constitute the power and flexibility of perl, I have absolutely no problem with the latter because I think quite flexibly.

In any case, this behaviour we see exhibited by List::Util::sum() might have been a genuine mistake or it might have been programmed in just the way it is for good reason. I just wonder what Graham Barr (the original author) has to say about it?


perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er

Replies are listed 'Best First'.
Re^8: List::Util::sum() and empty lists... (obvious)
by ikegami (Patriarch) on Dec 04, 2006 at 23:10 UTC

    I just wonder what Graham Barr (the original author) has to say about it?

    Maybe he did it for consistency. Every function in the module returns undef when given an empty list (except shuffle, which doesn't return a scalar).

    Maybe it didn't occur to him to check for that case, since sum is simply sub sum (@) { reduce { $a + $b } @_ }. (While the XS version explicitely returns undef, it probably came after the Perl version.)

      Maybe. Maybe not. Only he can confirm if it indeed is a genuine oversight or not.

      But since this behaviour is quite clearly documented in the POD for the module, and that the module has been around for almost a decade now, I'm not convinced the behaviour is due to an oversight. But again, the POD could be wrong or script-generated.

      Only Graham or P5P can give us a definite, authoritative statement for the reasons his module behaves the way it does, until then, it's play by the rules in the POD, i suppose?



      perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er

        that the module has been around for almost a decade now, I'm not convinced the behaviour is due to an oversight.

        Contrary to what's been said, undef is not the same as zero, so fixing it would break backwards compatibility. The greater the length of time since it has been decided, the harder it is to fix. It doesn't lessen the chance of it being an oversight.

        A reply falls below the community's threshold of quality. You may see it by logging in.
Re^8: List::Util::sum() and empty lists... (undefined)
by tye (Sage) on Dec 04, 2006 at 23:11 UTC
    because I don't have trouble understanding the value of zero/null/undef/nothing, they're all different words representing the same thing, mathematically or otherwise.

    "undef" means "undefined" which is quite different from "zero" or "nothing". Perl treats "undef" as zero (or the empty string) but only after emitting a warning. The warning is only required because "undefined" does not mean the same things as "zero", "nothing", nor "empty".

    In C, NULL mostly means "zero" but is often used for "missing" which might represent "undefined". In SQL, NULL means "not present" which is close to "undefined". The this built-in confusion on what "null" means could easily spread to confusion on what "undefined" means.

    If you called your bank and asked for balance and they said "I don't know; the computer system is down for maintenance and I can't look it up right now", then that would be getting a balance of "undefined" (or "unknown"). This is much different than a balance of "zero". Surely you can see that.

    So it appears that you do have a problem understanding a couple of those terms.

    - tye        

    A reply falls below the community's threshold of quality. You may see it by logging in.