Smarty parser was RE: [SMARTY-DEV] Regex bug?

A recursive descent parser can be a good idea only if it performs better than the regex-based parser. I think PHP is missing a "generic tokenizer" extension built-in in the language, I've suggested that to the PHP dev team some months ago and they concluded that someone who wants a built-in flex in PHP is crazy enough to be ignored :-)) I imagine a PHP parser will not be very fast unless the tokenizer can recognize tokens very fast from a list of regexes. But of course testing is free... > -----Original Message----- > From: boots [mailto:jayboots@yahoo.com] > Sent: Wednesday, May 07, 2003 1:04 AM > To: Smarty Dev > Subject: Re: [SMARTY-DEV] Regex bug? > > > --- Monte Ohrt <monte@ispi.net> wrote: > > It's not a bug. > > Well, its not a feature!! > > > You can never nest delimiters within delimiters in the Smarty > > language. The left delimiter works only because the parser > is looking > > for a right > > delimiter at that moment, this wasn't intentional. Don't bury > > delimiters > > within delimiters or the regex engine will come to haunt you. ;-) > > Maybe > > if Smarty had a better parser one day, but for now it is based on > > regex. > > Hmmm. That sucks. It won't even allow an {RDELIM} > (obviously). Can't we allow back-slash escaped delimiters > within delimiters? Or am I stuck, having to create $RDELIM > and $LDELIM as well? > > <off_topic> > Speaking of parsers, I wrote a very extendible (and > abstracted) class based stack parsing system that I believe > deals with this case, even though it was also regex based. I > abandoned it because it was too much work to maintain on my > own and though it was moderately fast, it was pretty rough, > especially when excellent projects such as Smarty had already > matured. Since Smarty is less generalized, it is even faster > ;). The biggest thing about it, though, was that you didn't > have to write regexs--it had external library(ies) of limited > regexes (which you could add to manually) and a very simple > language for capture patterns. It would compile that capture > patterns to regexes which were added to the library. You > could then base new patterns on already defined patterns, > mixing and matching libraries. > > It also supported generic replacement patterns (which could > be either preg_replace, preg_callback or preg_match based). A > new parser was arbitrary the combination of a ccapture and > replace. Parsers could nest other parsers which could either > be loaded from a library(ies) or created on the fly. Etc. I > implemented a few toy languages with it and a few text > transforms (like bb->html, etc). > > As I get more familiar with Smarty, I sometimes wonder if I > could implement Smarty's template language in my older > system. I think it would be neat if I re-imagined it as a > simple type of YACC/Bison which would have as a target PHP > regex based parsers. > > I suspect that better (non-regex) parsers can be built, but I > dread to consider the performance of a traditional parser > written in PHP. one thing about a generalized parser, though, > is that it can be implemented in C as a PHP module. > > Anyhow, I know that a new parser is being considered for > Smarty. I'm curious to see what the gang cooks up. :) </off_topic> > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > > -- > Smarty Development Mailing List (http://smarty.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >