tlm has asked me to recap the problem space for everyone's benefit. These equations are extracted from files of SPICE model parameters produced for either Cadence Spectre or HSPICE, which are electronic chip simulators that produce moment-by moment values for how chips behave. Each file contains model parameters for how transistors, capacitors, and such function in a given semiconductor process. The original SPICE simulator that all of these are based on was one of the very first non-OS applications written as Open Source in the 1970's, at UC Berkeley.
The grammar for these is both deep and recursively defined. Equations can have operators that range from ** down to && and ||, plus units scaling factors, and any given non-operator spot might hold a number, a variable, a library function, a user-defined function, an if-then-else, or another whole equation with or without parentheses. Most operators are left-associative, but ** and units are right-associative.
An example might be something like this:
foo = if bar >= 0 then if statistic_p(1, bar/3, 0) > 4 then 1.5u els
+eif statistic_p(1, bar/3, 0) > 2 then 1.2u else 1.0u endif else 0.5u
+endif
On top of all of that, == might be written as =, and elseif and elsif are equally valid. It's a hairy mess of a grammar, and our work is complicated by the fact that these values are not guaranteed to be provably correct, only that they will work on a certain high-dollar workstation we do not have the budget to buy. The code is littered with divide-by-zero's, parameters that are not defined in the code, and assumptions made by the workstation that are not documented. Top it off with the fact that the process we are designing for is being changed on the fly by the vendor, and it becomes quite probable that the values I'm given won't be useful two weeks after, so we really need this parser to fly!