If you're really that close to being complete then maybe I should just help push that over the finish line. Are you talking about support for tree grammars too?
Have you ever synced up with Yakimovich to see if your individual efforts could share anything from the other? On Thu, Oct 08, 2009 at 12:47:55AM +0530, Sidharth Kuruvila wrote: > 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
