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.1
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
1Perhaps 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.
In reply to Re^3: An anomaly with List::Util::reduce and/or eval? (XS)
by tye
in thread An anomaly with List::Util::reduce and/or eval?
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |