in reply to Re: optimizing a binary expression processor (revised)
in thread optimizing a binary expression processor

Two complaints.

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
    WRT error checking: It's a fair cop. I was demonstrating the data structure usage.

    As for the destructiveness: It's a feature, not a bug: It avoids redundant evaluation of shared subexpressions.

        -- Chip Salzenberg, Free-Floating Agent of Chaos