I think that in both cases (full parser vs. search and replace) you are creating a model of the language that you intend to transform. The search/replace model is just a lot more simple-minded than full parsing :)

Despite its simplicity, search and replace can work well in some situations. If one has a text file that is, e.g., line oriented, with lines being context free, there is a chance that search and replace operations on each line is all that is needed.

But most computer languages have hierarchy and some have recursion. This means that small bits of code are in effect context-sensitive: how they are interpreted depends on the surrounding text. So '&&' in a text string "$a && $b" means something very different in perl than a bare $a && $b. In this case, the best thing to do is to parse the whole file into an abstract syntax tree and compile that tree into new code according to your needs. For instance, many folks try to do search and replace on HTML code, which fails in all but the simplest cases. The answer is to use a parser like HTML::Parser to get what you need.

In your code above, it looks like you are translating Boolean expressions and using perl to 'eval' them. That may work with simple expressions of the form 'a && b', but what about nested expressions? Does Super Spice have the same operator precedence as Perl? Can you tell '&&' embedded in a comment from '&&' as an operator? It gets complicated.

So for all but the simplest grammars and transformations, it is best to parse.