Re: [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results

[Achim Gratz <Stromeko@nexgo.de>]

Eric Schulte writes:
> A hash marks a *result* with an indication of what was used to generate
> it (code block & parameters).  The point of a hash is to allow the
> result to be returned without having to re-execute.  For this reason, I
> think that the hash should live with the result.

Here Babel is assuming a very specific execution model, namely a
functional one (a function with the same parameters always delivers the
same results, so if you see the same function invoked with the same
parameters you can just substitute the result from an earlier
invocation).  Babel isn't a functional language however, so it is both
possible and done in practice to use it for side-effects or even
side-effects only.

But back to my earlier remark about the hash value actually being a
signature of the source block and not the result.  If I use noweb
references, the reference text is cached, not its expansion.  See the
example below where after the first invocation I change the source block
referenced to deliver a different result.  That invalidates the cache
for direct invocation of that block, but fails to do so for the indirect
invocation.  If you look at the two result blocks, you see that the same
hash is added to two different blocks.

--8<---------------cut here---------------start------------->8---
#+name: list
#+header: :exports none :results yes :eval query :cache yes
#+begin_src emacs-lisp
'(a b c d)
#+end_src

#+RESULTS[6bd0507c2cc972cc7647a9c2c169a1095bab5941]: list
| a | b | c | d |

#+RESULTS[d8dad02c5c6fd93a991a4bb23471f273cc0b3415]: list-1
| a | b | c |

#+name: indirect
#+header: :noweb yes
#+header: :exports none :results yes :eval query :cache yes
#+begin_src emacs-lisp
<<list>>
#+end_src

#+RESULTS[0b6ada101242e80d4d50f4909f33d8819a88ea4e]: indirect
| a | b | c | d |

#+RESULTS[0b6ada101242e80d4d50f4909f33d8819a88ea4e]: indirect-1
| a | b | c |
--8<---------------cut here---------------end--------------->8---

I'm not saying this needs fixing (expanding references could easily be
the most costly step in a re-evaluation), but the description in the
manual talks about caching in terms of results which is not what is
actually implemented, as demonstrated above.

> In general a hash without a result doesn't make sense (because then
> what is cached?).

If the question was meant as "did this code block already run?" and the
invocation was for side-effects only, then it does make sense to me.

> If one did want to move hashes to code blocks it would be a major
> refactoring which would (in my opinion) require significant
> justification.

I'm not disputing that it requires significant effort.  The benefits
would be that we might have a chance to clear up some confusion over the
code execution model of Babel and better support different ones.

> As I understand this particular case, the OP is using a hash not to mark
> a result as up to date, but rather to mark a side effect (loading data
> into R) as having taken place.  I think this is a misuse of a cache.

Or you might call it a clever hack.  But I think the general problem of
needing one-time invocations of source blocks is one that comes up often
when programming with side-effects that are not directly observable.
This again comes in different shades, I'd often want to run some blocks
only when the document is first opened, but then only again if something
changes.  This would require that the hash value was a property of the
buffer text, not actual buffer text, I'd think.  Sure, you can use hooks
to nuke the caches on load, but that only works when you are using your
own Emacs configuration.

> What if the R process restarts?  The hash would still be valid, but the
> side effects have been lost.  I think a better approach would be to
> implement the logic in R required to check if data is present and
> conditionally load it if not.  Then simply re-run this conditional
> reloading code in full every time.

Oh yes, there's a whole set of _other_ problems that are waiting to be
solved.  :-)


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada