On Thu, Mar 30, 2017 at 09:44:46AM +0300, Jarno Huuskonen wrote: > > With Thierry we've started to think about a stack-based > > expression evaluator which would make it trivial to concat strings > > and perform many other operations but we found that it will suffer > > from some deep problems like retrying failed fetches. > > Do you have any examples what kind operations could be possible with > the evaluator ?
The idea of a stack-based evaluator is that there would be no more difference between fetch functions and converters. All of them would consume between 0 and N operands on the stack and would push new ones on the stack. So in short, current sample fetch functions would only push operands on the stack without consuming any, and current converters would simply replace the last on-stack operand. So in order to perform a concatenation of two variables, you would push the two variables then apply the cat() converter : var(a),var(b),cat We can then imagine passing arguments to cat() to indicate how many operands to concat, or things like this. We could easily implement comparisons and arithmetic operations between multiple variables using this. The difficulty for now is that we could not easily restart a failed fetch, so we need to ensure that only the first one may be retryable, and that doesn't make much sense, as I'm pretty sure that many people will want to use external lookups (via Lua or SPOE) for some operations. > > Thus I think that for now we'll have to only implement a "concat" > > converter supporting a constant string and another one to concat a > > variable. Maybe we can call them "strcat()" for constant strings > > and "varcat()" for variable names. Is anyone interested in working > > on this ? > > I'm not volunteering (at least not yet:) but before strcat/varcat is > available maybe we could add couple of examples to configuration.txt > how you can do some concat functionality with headers ? Yes, feel free to propose some patches to improve the doc. We're missing a lot of examples in the doc in my opinion. > Do you see any use for simple substring replace (w/out regexps) ? Sure but before this we'd rather fix the expression parser, as it is impossible to pass a comma or a closing parenthesis in an argument and that significantly limits the extent of what could be done with regex. Willy
