The StructuredText parser I've been working on over the past few days simply kicks ass. I'm actually pretty proud of the code. I've whipped it out fast and it's designed really well, IMO.
One part of it, though, has been giving me a lot of problems. The inline parser, which parses the structure of an individual line, separate from the main parser which parses main blocks like paragraphs, blockquotes, and lists, has been a lot more difficult to write than the rest of the code.
Hmm... I entered the above into w.bloggar last night and saved it. I had planned on elaborating on why the inline parser has been difficult, and on describing the design of it, but I have no time now.
However, one of the decisions I'm going to have to make is a weird one.... I'm writing the thing in Python, because whenever I try to write anything big or complicated in PHP I wind up cursing PHP out every few minutes. Largely, I think, because I'm never sure that I'm not making copies everywhere because of PHP's broken OO. Whatever the reason, Python is just far more comfortable to work in, and I think my productivity has been much better with it than if I had written my code in PHP.
With that said, I'm only prototyping the code in Python. The "real" implementation is still going to be in PHP, since I want to use the code on my website, and well, my website is written in PHP. However, the Python code is much awesomer than the PHP code will wind up being. To give one example, in Python you get to say nice things like line = line[beginning:end] to suck out part of a line you're interested in. In PHP I'm going to have to say $line = substr($line, $beginning, $length-$end). After looking at that, I'm beginning to think that dollar sign variables aren't so hot.
So this leaves me with the prospect of wanting to maintain both the Python and the PHP versions of the code. The difficulty is exacerbated because the code is much more than just the base parser. It's "pluggable", so you can add new content types (like, in addition to paragraph, blockquote, etc., you can add "code block", "note", "user-entered text", etc.), parser components (for instance, a different list syntax or a different table syntax, and a parser for "note", "code block", etc.), and for each content type, you have to add a "generator" for your destination language, it being HTML, LaTeX, etc. And, realistically, I'd much rather maintain and use the Python version, especially for anything but HTML generation, since it integrates better with my computer than PHP does, rather than my web server, which is what PHP specializes in.
So, I guess I've made my decision. This is why I write things like this out sometimes 
I think the primary version will be the Python version, and the PHP version will always be a simple translation of the Python version. I'll make both available for download. At the very least it'll serve as an interesting language comparison Unfortunately, it's not going to get finished until I get that line parser thing figured out, and that's not going to happen until after finals, and until after my road trip (yeah baby) after that.
Sunday, May 11, 2003
Permalink
I think there's an extension to php that lets you store python code in a php string (ie read from your .py file) and execute it in a php script, FYI.