I think you're overcomplicating matters; the algorithm as it stands will evaluate a function's arguments before any operators that operate on the result of the function. This is because the right-parenthesis rule pops the entire function and its arguments off the stack in one go. By the time you find that operator in your example, the whole function should already be in the output queue. There should be no function on the stack.

I don't think anything is wrong with it. It's result should be 4. This is the output queue that I got when I tested it: 1 2 add 1 +

And if I try that out:

1      12      1 2add    31      3 1+      4

Works good.

Just because it gives you the right answer, doesn't mean you've implemented the algorithm correctly. If you had "2+2" and used multiplication instead of addition, that would "work good" too, even though the algorithm is wrong.

As I said, by the time you get to the operator after the function, there should be no function on the stack, and therefore no need at all to worry about precedence. If you're having to use precedence rules to compare the operator to a function on the stack, then you haven't implemented the algorithm as it was documented.

I'm not entirelly sure what happened with the algorithm. All I did was add "||(cur.type == FUNCC)" and it worked fine.

I tested that expression out, and you were right:

add(1,2)+1add			add(			( add1	1		( add,	1		( add2	1 2		( add)	1 2 add+	1 2		+1	1 2 add 1 	+

I don't know what happened to the algorithm, but, aslong as it works, and it's robust, I don't have a problem with it :)