Hi Geoff, When I say easy I mean it's not particularly mentally challenging since Php maps amazingly well to Java, except for a few minor issues like the missing try finally. So the problem is more about transliterating the code from java to php. The way I went about this was implementing the test cases from the python runtime and then rewrite bits that failed till i got the tests to pass. This is a slow iterative process. One you won't be able to avoid even if you chose to go for a c runtime + a php parser.
It's definitely something I would love to get finished quick if there is interest in it, so specific tickets for specific requirements could speed things up. But I can't tell right now how long it might take. I doubt it would take much more time that implementing the c runtime + php code generator route you suggested. Personally I'd love to see both the c runtime and a php runtime for choice :). Regards, Sidharth On Wed, Oct 7, 2009 at 11:09 PM, Geoff Speicher <[email protected]>wrote: > Can you define "fairly easy" and "grunt work" please? :) > > I did see both projects, but I was not able to find information > about what was complete versus what remained, for both the code > generation target and the runtime. I guess my whole point is, if > all the grunt work can be avoided, why not spend our time where > it's needed? > > Just to make sure we're all on the same page, the idea is: wrap > the existing runtime library into a PHP extension so that the > C or C++ API is available to native PHP code at runtime, just > like the mysql_* functions or the ZipArchive class. Then add a > generation target that produces native PHP code that uses the API > exposed through said extension. > > It should be faster even than cached PHP bytecode, and the work > that already goes into the maintenance of the C/C++ runtime > libraries would not need to be duplicated. > > Unless, of course, it would take less time to finish what you > have started. :) > > > On Wed, Oct 07, 2009 at 10:14:09PM +0530, Sidharth Kuruvila wrote: > > Hi, > > > > It's fairly easy to port antlr to php, though it does involve lots of > grunt > > work. I've already done some work on a php runtime if you are interested > in > > looking at that. > > > > http://code.google.com/p/antlrphpruntime > > > > Yauhen Yakimovich was looking at this too, not sure how far he's gotten. > > > > Regards Sidharth > > > > On Wed, Oct 7, 2009 at 9:31 PM, Geoff Speicher > > <[email protected]>wrote: > > > > > I see there is a native runtime for PHP in the works. > > > > > > Has there ever been any discussion as to whether it would make > > > sense, as an alternative to a native PHP runtime, to wrap the > > > existing C (or C++) ANTLR runtime into a PHP module? In theory, > > > this should provide a fast PHP target, without the work of having > > > to write and maintain a separate PHP runtime. > > > > > > This is something that I am interested in doing in the near term > > > unless someone knows of a reason why it wouldn't work. > > > > > > Geoff > > > > > > _______________________________________________ > > > antlr-dev mailing list > > > [email protected] > > > http://www.antlr.org/mailman/listinfo/antlr-dev > > > > > > > > > > > -- > > I am but a man. > -- I am but a man.
_______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev
