<p>As a side note, the module can still be improved with a series of fixup optimizations which include pvar handling (token should include an un-evaluated pv_spec_p struct) in order to avoid expression parsing at runtime. I should put this on the TODO list :)</p>

<p>A couple of quick ideas related to the pull request:</p>

<ul>
<li>Reverse Polish notation is HIDEOUS. Humans hate it and parsers love it. I have some doubts about the module exposing a function that takes non-intuitive inputs. Building code on top of existing code (i.e. enhancing math_eval with maintaining proper operator priorities), and hiding the internal logic would be a better approach.</li>
<li>it looks like parsing will fail with "math_rpn("2 1 1 +*", "$var(res)")" (maybe I'm wrong!)</li>
<li>please use tabs for code indenting! (you can configure your editor afterwards for 2-char-wide tabs)</li>
<li>try to be consistent with existing code. Not "for ( i.." but "for (i...". Not "if(..." but "if (...")</li>
</ul><p>To better understand reason 1), I give you the following exercise:<br>
Convert "1 + exp(10, 5) - 2 * 2" in RPN. How long did it take you? :)</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br>Reply to this email directly or <a href='https://github.com/OpenSIPS/opensips/pull/144#issuecomment-29552893'>view it on GitHub</a>.<img src='https://github.com/notifications/beacon/cHRwG-eeZpfKR_UBFXzvRCSdB-4bzhGpw_FHpTRchb-O-OPsLgjp-LRF_24hHyRs.gif' height='1' width='1'></p>