In a new post to his blog Sameer Borate shows how to create a lexer and parser in PHP to work directly with the tokens of a PHP script.

After looking around for a while [for a good resource on compilers] I settled for Terence Parr's Language Implementation Patterns. This is exactly what I needed - bit sized patterns on compiler and parser design with working code. The book provides a recipe style approach, gradually moving from simple to complex compiler/parser design issues. As I primarily work with PHP, I thought of porting some code to PHP to see how it works.

He shows examples using his custom tool to show a basic lexer output for a list and a complete listing of the code involved. Ultimately, though, he finds that PHP isn't overly suited to the task - anything more than his simple example could be more trouble than it's worth.

Erik has posted about a new parser he's created, one based on the LALR parser method, that can be downloaded here [zip].

Parser tables, along with a lexer table, are the core constituents of any compiler's front end. This LALR parser generator is heavily based on my custom Php version of the map/reduce programming technique (functional programming). I will elaborate in future posts, on why I used a map/reduce basis to implement the parser generator.

Parsers organize a set of tokens based on the rules of a formal language the parser is given. Several of the grammar text files are included in the download so you can test it out for yourself. For more on the topic check out these two posts.

In a (slightly inflammatory) post to his blog today Erling Alf Ellingsen shares why he thinks that "PHP must die", mostly due to some of the inconsistencies his has with other languages.

His examples include:

• String vs. numeric handling
• That PHP supports octal numbers "by accident"
• A lexer bug with hex values
• A parser bug involving the ternary operator

Comments on the post include those supporting the "die" opinion - that PHP just doesn't have it together like other languages - and those taking a bit more balanced approach on PHP's strengths and weaknesses.

Phil Sturgeon has a new post to his blog talking about a way to give your CodeIgniter site a bit more "pep" - use his updated implementation of the Dwoo templating engine.

Not wanting to spend too much time re-inventing the wheel I had a look at existing templating engines and decided to use Dwoo. [...] So after a little head-scratching, we now have CodeIgniter-Dwoo. DwooParser? DwooIgniter? Whatever we call it, my new Dwoo implementation for CodeIgniter sits in with "the CodeIgniter way" perfectly and the only code you will need to change within your application is the Parser file and your view files. No changes to your controllers at all!

You can download the library from the code section of his site.

On the PHP::Impact blog today Federico points out a few HTML DOM parsers that work similar to jQuery:

• the Simple HTML DOM Parser
• Zend_Dom_Query
• phpQuery

Check out a previous tutorial of his for more information on using DOM parsers to scrape information from remote sites.

Skaldrom passed along a link to an article he's written up to show how to use one of the more powerful PEAR packages in a simple "Hello World" kind of script - the PHP_LexerGenerator and PHP_ParserGenerator packages.

Who doesn't dream about it: Your own programming language, because the syntax and the word are expression! A step continue to go to ascend and from the programming language user to the language creator! This is now possible in PHP, but unfortunately only with minimum documentation.

He provides an example of the Lexer/Generator in action - handling a simple mathematical operation. The execution code is first with the Lexer definition file and the code for the parser following. Lastly, he has included the code to make things work - passing the test string into his custom Lexer which is passed off to the Parser and a value returned.

David Coallier has a quick hit post today on his blog. In it, he shows how, with a little bit of SimpleXML magic, to parse the log files from your Subversion installation.

Yesterday I was struggling trying to get svn log to display the results for a certain user and this was very annoying.. then I jumped on #svn on freenode, and someone mentionned svn log --xml

This apparently made my life much much easier with this simple script I have pulled in a couple minutes.

He includes the script and a brief set of instructions on how to use it in your installation.

On Pàdraic Brady's blog, he talks about some thought he had on a YAML component for the Zend Framework and some of the feedback he's gotten so far.

Since I'm used to the format from Ruby and Perl and since it's used for a similar purpose in the PHP Symfony framework, I also suggested using YAML configuration files since they are far more readable than XML and remain machine readable. I believe this went over quite well. Later on I realised the Zend Framework has no YAML support, and after some searching noticed the only (apparent) PHP parser was the Spyc library

So I fired off a few emails to the fw-general mailing list of the Zend Framework to see if there was any interest. I'd like to thank Matthew and Gavin for their feedback and I've since decided to have a go at implementing a YAML parser in PHP.

He notes that there is already a YAML parser for PHP5 (Syck), but that creating one for the Zend Framework is a different animal. He finishes up the post talking about where to start with the parser, what it is, and the next steps for him in its development.

When finding he was in need of a parser and lexer, Wez Furlong decided to work up one that was PHP-based and a take off of the popular lemon parser and JLex lexer.

From time to time, I find that I need to put a parser together. Most of the time I find that I need to do this in C for performance, but other times I just want something convenient, like PHP, and have been out of luck.

His result is two new packages - lemon-php and JLexPHP (under a BSDish license) you can download and compile on your own system.

Also, if you'll remember a while back, Greg Beaver had wanted something similar (as mentioned in the comments) and created his own lexer/generator as well.

Greg Beaver has blogged today with more about the port he's been wokring on of the Lemon parser generator to PHP5, this time discussion the creation of two packages - PHP_ParserGenerator and PHP_LexerGenerator.

Last week, I blogged about completing a port of the Lemon parser generator to PHP 5, which I thought was pretty cool. However, in an email, Alex Merz pointed out that without a lexer generator to accompany lemon, it's pretty difficult to write a decent parser.

After Alex's email, I started thinking about what it would take to write a lexer generator. Basically, a lexer generator requires parsing and compiling regular expressions, then scanning the source one character at a time to find matches. So, it occurred to me that perhaps simply combining regular expressions with sub-patterns could accomplish this task quite easily.

He goes on to explain this process, showing how a simple regular expresion call (and a look at its return arguments) could create a simple, easy solution. Since the re2c format is still unsupported in PHP (without a goto to go to), he opts to stick with the regular expressions and creates a "lex2php" format instead.

He's packaged up both halves of this setup and has already posted proposals for them to the PEAR site:

• PHP_LexerGenerator
• PHP_ParserGenerator