• Input: Out of sight, out of mind
• Output: A blind idiot

As I contemplate it. It could be done in phases. Using SED, I would bite off,gulp,slurp chunks of tags (language constructs) I recognize, and separate them into categorized groups -- functions,(s)print(f)'s,...

Then, I could translate the actual Language bits, ignoring the other stuff as pretty much being equivalent(s) in Perl. Then (somehow) reconstruct it all -- which is another puzzle in, and of itself.

This is, of course, pretty simplified. But in my mind, seems a reasonable path.

--Chris

#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;

Why would you want to use sed when the Perl regexes are far far far more powerful?

If you feel limited in your command of Perl regexes, I really think that the first thing you want to do is to really start mastering the Perl regexes. Perhaps reading Mastering Regular Expressions, by Jeff Friedl. BTW, this book also shows some of the limitations of regexes, and you project will necessarily meet these limitations. I think that most people on this forum agree that you should not use regexes for parsing HTML or XML, using regexes for parsing PHP would be even worse.

Although regexes might certainly do part of the work, I doubt that you can go anywhere without using a real parser.

One final note on the English-Russian translation anecdote, I personally tried several translating software packages over the years (I was a translator before I became a CS professional) between 1988 and 1996. The results were really bad. On the first one I tried, i gave the following sentence: "Time flies like an arrow". The French translation I obtained was: "Les mouches du temps aiment une flèche", which can be translated back into English as follows: "The flies (the insect) of time love an arrow". I tried other packages at the time, the results were possibly not as funny, but not much better. A lot of improvements have been made since, but the basic problem of implicit context understanding is still there.

Greetings Laurent_R, and thank you for your reply.

"Why would you want to use sed when the Perl regexes are far far far more powerful?

If you feel limited in your command of Perl regexes, I really think that the first thing you want to do is to really start mastering the Perl regexes.

In my humble defense; I made note of this on two occasions early in this thread.

But yes. Agreed.

My choice of referring to SED in this case, is because I can think further with it, because I'm more familiar with it. But assumed that I could (with greater knowledge) accomplish / achive as much with the Perl RE.

Which is why I thought this strategy would work, the way I indicated.

Best wishes, and thanks again for responding.

--Chris

#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;

There’s no doubt, of course, that valid PHP can be parsed, for syntax checking and so-on, and that once the source has been reduced to an abstract-syntax tree (AST) form, some of those AST constructs could be expanded into Perl.   The languages are in many ways very similar.   You might be able to do such a thing, say, in an editor-macro for a very smart editor.

If you look beyond the superficial, though, you start getting into some much thornier problems.   For example, in the PHP system, “everything is compiled-in,” and is called by means of (hundreds of ...) functions.   Database access, for example, is implemented in that way.   In the Perl system, per contra, we have DBI.   Now you are going to have to develop a way for the translated Perl code to continue doing things “the PHP way.”   Suddenly, your problem has become quite a bit more complicated, and pretty soon “diminishing returns” are going to be a factor.   And then, there are the ideas that simply do not exist at all in Perl, such as the intermingling of HTML and PHP in a file, which was a founding concept of PHP.

"And then, there are the ideas that simply do not exist at all in Perl, such as the intermingling of HTML and PHP in a file, which was a founding concept of PHP."

This is something that's actually incredibly easy to implement. This PHP:

?>Hello<?php
[download]

Becomes this in Perl:

print "Hello";
[download]

There are far harder things to implement - PHP's idea of arrays differs greatly from Perl's; PHP has different ideas about passing arguments to functions by value or reference; different variable scoping; different behaviour of the ==, <, >, etc operators; and so on.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

I am not so sure. The thing is that natural languages aren't really that analogous to programming languages here, because they aren't that ambiguous. Natural languages are defined by use, not by specification. Programming languages are defined by specification and not by use. Of course that specification is written in a language defined by use, but since you have only one canonical implementation of PHP and only one of Perl, you might be able to say that the implementation is authoritative. Because in the end, the basic structures are identical, you shouldn't have problems translating programming languages that you do with natural languages.

But that leads to a big problem in that to be perfect, a perfect converter would have to translate bug for bug but that's not very feasible, but you could still have something which manages those to an extent. You could have wrapper classes for ordered maps and translate PHP arrays to that. However very likely what you would have to end up with is a program that converts from PHP into a Perl framework built for the conversion.

Now where I think your point holds some real weight is in the management of code comments. What does the program do with those? Just ignore them? Just include them? Both of those seem dangerous, and you can't translate them for the reason you mentioned.