The first is that you are editing the input data structure destructively, in place. I would far prefer to use a map statement rather than looping over @_ in place.
The second is a complaint about eval's trapping of errors. Sometimes you want it, and sometimes you don't. With autogenerated code I generally don't. But as it stands I need to either live without (ie trust that your code works as it stands) or else catch your output, look at $@, and only then issue an error or else return the results. (And, of course, to do that right you need to propagate context.)
Which is enough of a headache that I almost never see people do it. For instance in the above you use a warn for debugging. But if you had a large data structure, that trace would become unreadable, hence would be turned off. And then if you were passed a data structure that was wrong somewhere, little hint would be given as to where you had the problem. For instance consider:
print proc([2, '+', 2], '*', [3, '+']);
In reply to Re (tilly) 2: optimizing a binary expression processor (revised)
by tilly
in thread optimizing a binary expression processor
by princepawn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |