Forgive me Tye,

Examine what is said.

I really thought that I had, and was responding to what you had said. I'll admit that I took a few leaps forward from your exact words to what I considered to be their logical conclusion. Namely:

• That code should not be optimised as it it harder to get right and that using C (via XS) to code something that can be coded in Perl is an undesirable thing to do for that reason.

If this is a misinterpretation of your words or intent, I apologise.

I'll readily admit to being anything but an expert in either the perl sources or XS, but when I looked at the source for sort and attempted to compare it with the source for reduce, I found the following two routines

static I32
sortcv_xsub(pTHX_ SV *a, SV *b)
{
    dSP;
    I32 oldsaveix = PL_savestack_ix;
    I32 oldscopeix = PL_scopestack_ix;
    I32 result;
    CV *cv=(CV*)PL_sortcop;

    SP = PL_stack_base;
    PUSHMARK(SP);
    EXTEND(SP, 2);
    *++SP = a;
    *++SP = b;
    PUTBACK;
    (void)(*CvXSUB(cv))(aTHX_ cv);
    if (PL_stack_sp != PL_stack_base + 1)
    Perl_croak(aTHX_ "Sort subroutine didn't return single value");
    if (!SvNIOKp(*PL_stack_sp))
    Perl_croak(aTHX_ "Sort subroutine didn't return a numeric value");
    result = SvIV(*PL_stack_sp);
    while (PL_scopestack_ix > oldscopeix) {
    LEAVE;
    }
    leave_scope(oldsaveix);
    return result;
}

void
reduce(block,...)
    SV * block
PROTOTYPE: &@
CODE:
{
    SV *ret;
    int index;
    GV *agv,*bgv,*gv;
    HV *stash;
    CV *cv;
    OP *reducecop;
    PERL_CONTEXT *cx;
    SV** newsp;
    I32 gimme = G_SCALAR;
    U8 hasargs = 0;
    bool oldcatch = CATCH_GET;

    if(items <= 1) {
    XSRETURN_UNDEF;
    }
    agv = gv_fetchpv("a", TRUE, SVt_PV);
    bgv = gv_fetchpv("b", TRUE, SVt_PV);
    SAVESPTR(GvSV(agv));
    SAVESPTR(GvSV(bgv));
    cv = sv_2cv(block, &stash, &gv, 0);
    reducecop = CvSTART(cv);
    SAVESPTR(CvROOT(cv)->op_ppaddr);
    CvROOT(cv)->op_ppaddr = PL_ppaddr[OP_NULL];
#ifdef PAD_SET_CUR
    PAD_SET_CUR(CvPADLIST(cv),1);
#else
    SAVESPTR(PL_curpad);
    PL_curpad = AvARRAY((AV*)AvARRAY(CvPADLIST(cv))[1]);
#endif
    SAVETMPS;
    SAVESPTR(PL_op);
    ret = ST(1);
    CATCH_SET(TRUE);
    PUSHBLOCK(cx, CXt_SUB, SP);
    PUSHSUB(cx);
    if (!CvDEPTH(cv))
        (void)SvREFCNT_inc(cv);
    for(index = 2 ; index < items ; index++) {
    GvSV(agv) = ret;
    GvSV(bgv) = ST(index);
    PL_op = reducecop;
    CALLRUNOPS(aTHX);
    ret = *PL_stack_sp;
    }
    ST(0) = sv_mortalcopy(ret);
    POPBLOCK(cx,PL_curpm);
    CATCH_SET(oldcatch);
    XSRETURN(1);
}
[download]

The former is only that part of sort that deals with the setting of $a & $b, calling the comparator and retrieving & returning the result. Ie. That bit that is directly analogous to the reduce code, and to my eyes they are very similar. The latter example is more complicated, but then the former is only 28 lines from nearly 2000 that implement the built in sort. Many of the macros used seem (to my inexperienced eyes) to be very similar.

So, whilst I wasn't asserting that they were the same, I was suggesting that the level of difficulty in developing bug-free routines in either was similar. To my knowledge List::Util is fairly immature code relative to sort--even the latest implementation of which are derivative of prior art and show the hands of many people in its evolution--so I find it unsurprising that there are still bugs. Only through use will these be discovered and corrected.

But you tell me, why would one have the same functionality written in both Perl and XS?

In a way, that was my point exactly. sort could be provided as a pure perl implementation. The reason it isn't is mostly performance. The frequency of use, and therefore the frequency (as well as the size) of the performance gains that accrue from implementing it in C (or XS which resolves to C) are such that the extra work involved is deemed worth it.

I contend that reduce is a similarly, generically useful routine that it too will benefit the many by the extra effort expended by the few to make it run as efficiently as is practical. That List::Util has been adopted into the core whilst still remaining an extension rather than being moved into the perl source proper indicates that perhaps others hold similar views. It may well mean that the move was premature as there are still bugs, but as I said previously, there are still bugs in the perl source proper (eg.substr), so it's really a matter of opinion.