"J Pedro Fonseca" <j-pedro-fonseca@telecom.pt> writes: > My idea for a Perl interpreter is like this: > > [Code Parser] -> [Intermediate Representation of the Code]-> > ->[Interpreter runs Code] > > So, what you are proposing is to have Perl (5 or 6) to parse de code, > and interpret the intermediate representation of the code? That will > really be slow... No. The proposal seems to be to write the parser in a (subset of) perl, which is then turned into C/Scheme/C++/whatever, which is then compiled. Assuming that the perl->C/Scheme/C++/whatever stage is good and efficient and the backend compiler is also good at it's job then the resulting parser should also be quick. It seems to me (as someone who doesn't like programming in C) that this gives a fair few programmer efficiency wins once the code generator is up and running. It should also be possible to profile the resulting parser and move the implementation of certain features from perl to hand optimized back end code (in a manner reminiscent of the current 'Hmm... that's slow, better do it in XS' approach but with (hopefully) a somewhat more friendly syntax), but that would only be required late in the development cycle. Of course I say all this as someone who has done very little for the current version of perl beyond just using it. However, if it were possible to write more of perl in Perl then I'd relish doing more work. -- PiersThread Previous