It's a little more than a regexp problem. You can't exactly substitute a PHP array with a Perl array, or even a Perl hash, because the PHP array is actually an ordered map. An ordered map has different performance and semantic characteristics from a Perl array or a Perl hash. And that's just where the differences begin.
A human can look and say, "That algorithm that uses a PHP array can be expressed with a Perl array." Or "This other algorithm needs a Perl hash." Or "This algorithm is going to require a hash, and an array crossreference to maintain order." A dumb tool would be forced to make compromises in every case; it would have to maintain the hash, and an ordered list to emulate an ordered map. This is not to say that an ordered map is more powerful, but that it's a different container. In specific cases, Perl could mimic enough of its behavior using an array, and in others, enough of its behavior using a hash. But in a general case, both would have to be used together. Programming for the general case, then, would be inefficient for many specific uses. A human can make the distinction, or even rewrite the algorithm to play to Perl's strengths instead of PHP's strengths.
Once that problem is solved, there will be many more paradigm mismatches, each one that could be gracefully handled by a human, but where a machine would need to understand the underlying purpose of code segments, which is probably beyond the capabilities of any regexp engine.
| [reply] |
| [reply] |