Well, you do have that choice. Delete the dll or unix equivalent and the code falls back to a pure perl version.

Mind you, there is no guarentee that the perl version will be bug-free.

Nor is there any evidence that shows this to be a bug that results from an optimisation, unless you consider writing anything in XS an optimisation? In which case maybe we should revert to a pure perl implementation of sort, map etc.?

I mean. Last week I found a bug in substr. Was that also a csae of "over-optimisation"?

anything in XS an optimisation? In which case maybe we should revert to a pure perl implementation of sort, map etc.?

Are you trying to assert that sort and map are implemented via XS? My objection is about XS code, not that the Perl source code is written in C.¹

Mind you, there is no guarentee that the perl version will be bug-free.

There are few true guarantees in life. I'm not sure why you felt I was trying to offer one or assert the existence of one. But I'd be happy to bet you that this bug will go away if you follow your own instructions on how to remove the XS code. My assertion is that XS code is more likely to be buggy than Perl code. Actually, I find it to be far more likely to be buggy.

Nor is there any evidence that shows this to be a bug that results from an optimisation, unless you consider writing anything in XS an optimisation?

No, I don't consider writing anything in XS to be an optimization. But you tell me, why would one have the same functionality written in both Perl and XS? Why is the XS code present in this case? I'm pretty sure the primary (probably only) reason for this XS code is an attempt to increase "performance".

Examine what is said.

                - tye

¹Perhaps you would like to implement "reduce" as a Perl keyword and then compare the resulting code to the current XS code in order to appreciate that the two ways of implementing Perl functionality in C are quite different. Then try to get your code included into Perl and compare that to getting your XS code into CPAN.

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

Read more... (2 kB)

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.

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.