diff --git a/org-babel.org b/org-babel.org index 99f933679..1f9eba34e 100644 --- a/org-babel.org +++ b/org-babel.org @@ -208,152 +208,6 @@ would then be [[#sandbox][the sandbox]]. * Tasks [35/57] -** PROPOSED implement fully recursive evaluation machinery - The current parser / evaluator fails with greater levels of nested - function block calls (example below). If we want to overcome this I - think we'd have to redesign some of the evaluation - mechanism. Seeing as we are also facing issues like dealing with - default argument values, and seeing as we now know how we want the - library of babel to behave in addition to the source blocks, now - might be a good time to think about this. It would be nice to do - the full thing at some point, but otoh we may not consider it a - massive priority. - - AIui, there are two stages: (i) construct a parse tree, and (ii) - evaluate it and return the value at the root. In the parse tree - each node represents an unevaluated value (either a literal value - or a reference). Node v may have descendent nodes, which represent - values upon which node v's evaluation depends. Once that tree is - constructed, then we evaluate the nodes from the tips towards the - root (a post-order traversal). - - [This would also provide a solution for concatenating the STDOUTs - of called blocks, which is a [[*allow%20output%20mode%20to%20return%20stdout%20as%20value][task below]]; we concatenate them in - whatever order the traversal is done in.] - - In addition to the variable references (i.e. daughter nodes), each - node would contain the information needed to evaluate that node - (e.g. lang body). Then we would pass a function postorder over the - tree which would call o-b-execute-src-block at each node, finally - returning the value at the root. - - Fwiw I made a very tentative small start at stubbing this out in - org-babel-call.el in the 'evaluation' branch. And I've made a start - at sketching a parsing algorithm below. - -*** discussion -I believe that this issue should be addressed as a bug rather than as -a point for new development. The code in [[file:lisp/org-babel-ref.el][org-babel-ref.el]] already -resolves variable references in a recursive manner which *should* work -in the same manner regardless of the depth of the number of nested -function calls. This recursive evaluation has the effect of -implicitly constructing the parse tree that your are thinking of -constructing explicitly. - -Through using some of the commented out debugging statements in -[[file:lisp/org-babel-ref.el][org-babel-ref.el]] I have looked at what may be going wrong in the -current evaluation setup, and it seems that nested variables are being -set using the =:var= header argument, and these variables are being -overridden by the *default* variables which are being entered through -the new functional syntax (see the demonstration header below). - -I believe that once this bug is fixed we should be back to fully -resolution of nested arguments. We should capture this functionality -in a test to ensure that we continue to test it as we move forward. I -can take a look at implementing this once I get a chance. - -**** demonstration - -After uncommenting the debugging statements located [[file:lisp/org-babel-ref.el::message%20format%20first%20second%20S%20S%20new%20refere%20new%20referent%20debugging][here]] and more -importantly [[file:lisp/org-babel-ref.el::message%20nested%20args%20S%20args%20debugging][here]], we can see that the current reference code does -evaluate the references correctly, and it uses the =:var= header -argument to set =a=8=, however the default variables specified using -the functional syntax in =adder(a=3, b=2)= is overriding this -specification. - -#+srcname: adder(a=3, b=2) -#+begin_src python -a + b -#+end_src - -#+resname: adder -: 5 - - -#+srcname: after-adder(arg=adder(a=8)) -#+begin_src python -arg -#+end_src - -#+resname: after-adder -: 5 - -*** Parse tree algorithm - Seeing as we're just trying to parse a string like - f(a=1,b=g(c=2,d=3)) it shouldn't be too hard. But of course there - are 'proper' parsers written in elisp out there, - e.g. [[http://cedet.sourceforge.net/semantic.shtml][Semantic]]. Perhaps we can find what we need -- our syntax is - pretty much the same as python and R isn't it? - - Or, a complete hack, but maybe it would be we easy to transform it - to XML and then parse that with some existing tool? - - But if we're doing it ourselves, something very vaguely like this? - (I'm sure there're lots of problems with this) - -#+srcname: org-babel-call-parse(call) -#+begin_src python - ## we are currently reading a reference name: the name of the root function - whereami = "refname" - node = root = Node() - for c in call_string: - if c == '(': - varnum = 0 - whereami = "varname" # now we're reading a variable name - if c == '=': - new = Node() - node.daughters = [node.daughters, new] - new.parent = node - node = new - whereami = "refname" - if c == ',': - whereami = "varname" - varnum += 1 - elif c == ')': - node = node.parent - elif c == ' ': - pass - else: - if whereami = "varname": - node.varnames[varnum] += c - elif whereami = "refname": - node.name += c -#+end_src - -*** Example that fails - -#+srcname: adder(a=0, b=0) -#+begin_src python -a+b -#+end_src - -#+srcname: one() -#+begin_src python :results silent -1 -#+end_src - -This works -#+srcname: level-one-nesting -#+begin_src python :var arg=adder(a=one(),b=one()) -arg -#+end_src - -But this doesn't -#+srcname: level-one-nesting -#+begin_src python :var arg=adder(a=adder(a=one(),b=one()),b=adder(a=one(),b=one())) -arg -#+end_src - ** PROPOSED Default args This would be good thing to address soon. I'm imagining that e.g. here, the 'caller' block would return the answer 30. I believe