in reply to optimizing a binary expression processor

How about a totally new approach:

sub proc { for (@_) { $_ = proc(@$_) if ref } warn "EXPR @_\n"; eval "@_"; }

    -- Chip Salzenberg, Free-Floating Agent of Chaos

Replies are listed 'Best First'.
Re (tilly) 2: optimizing a binary expression processor (revised)
by tilly (Archbishop) on Nov 14, 2001 at 16:38 UTC
    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, '+']);
      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