in reply to Re: optimizing a binary expression processor (revised)
in thread optimizing a binary expression processor
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, '+']);
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Re (tilly) 2: optimizing a binary expression processor (revised)
by chip (Curate) on Nov 17, 2001 at 03:29 UTC |