Re: [O] babel header arguments tutorial?

[Nick Dokos]

Lawrence Bottorff <address@hidden> writes:

> I guess from a purely elisp perspective I'm baffled. How is
>
> #+begin_src emacs-lisp
>   org-babel-default-header-args:Python
> #+end_src
>
> supposed to produce
>
> #+RESULTS:
> | (:session . foo) |
>
> as it supposedly does in the doc? It doesn't for me. (Where, e.g., would 
> "foo" be coming from?) If it had worked, does it make an addition to some 
> hash table, or an alist somewhere?
> But then running this as an elisp code block is cool from a declarative 
> programming standpoint (see this) . So this
>
> # Local Variables:
> # eval: (setq-local org-babel-default-header-args:Python '((:session . 
> "foo")))
> # End:
>
> is called when you eval-buffer or open the file? 
>

When you open the file. But see some caveats in my reply. Charles
Berry's reply shows the preferred method today, using only what's
available in org, but does not shed any light on the local file
variables question (which is a more general mechanism, available
throughout emacs, not just with org files).

Assuming that you want to learn about file variables, we will forget
temporarily about Charles's reply.

So when you open the file, the local variables section is found and
evaluated. Any variable settings are automatically buffer-local.
That's what sets the org-babel-default-header-args:python variable
to '((:session . "foo")) - in that buffer only.

Then when you go evaluate the code block

#+begin_src emacs-lisp
org-babel-default-header-args:python
#+end_src

the variable has the give value and produces a result

#+RESULTS:
: ((:session . foo))

But if you evaluate the same code block in some other buffer, the
result will be nil (unless you have initialized in some other way
of course, e.g. by adding the initialization to your .emacs).

> Ancillary questions:
> 1. can babel elisp (or CL) blocks be assigned/associated to a
> specifically named session?
> That would enable various elisp code blocks to have separate "session
> spaces" (as does the geiser/scheme babel). If so, I'm guessing the
> block-session communication could also be remote? Again, with babel
> geiser/scheme sessions, can they call "cached" things from each
> other's different sessions?
>

Theoretically, maybe (how's that for exactness?), but there are babel
implementations that don't support sessions at all and (depending on the
underlying interpreter), there may be subtle (or perhaps not so subtle)
differences in evaluation semantics. Some experimentation should provide
answers, but N.B. that the answers may be accidents of implementation
(which some might call "bugs"). I don't think there is a strictly
defined session model that applies to all languages: the implementations
do the best they can under these circumstances.

Now this is more a hunch than anything else: I *think* that's the way
things are but I may be wrong, out-of-date, or both. A set of
well-designed experiments in as many languages as possible would clarify
the situation, and perhaps lead to improvements (they could also be
turned into unit tests, which would be very desirable) - I won't
volunteer, but maybe you would?

> 2. . . . which makes me wonder how code blocks in a buffer can be run besides 
> manually C-c C-c ing them. For example,
>
> #+name: myexptdouble
> #+begin_src emacs-lisp :session
> (defun myexptdouble (x y)
>   (* (myexpt x y) (myexpt x y)))
> #+end_src
>
> #+RESULTS: myexptdouble
> : myexptdouble
>
> #+name: myexpt
> #+begin_src emacs-lisp :session
> (defun myexpt (x y)
>   (expt x y))
> #+end_src
>
> #+BEGIN_SRC emacs-lisp :results output raw
> (myexptdouble 2 3)
> #+END_SRC
>
> Even if I manually evaluate myexptdouble, running the last block gives an 
> error about not knowing what myexpt is. Is there something in the last block 
> that can be told to evaluate all
> the dependent functions? Perhaps if my blocks are named the same as the 
> function name? How tangling and preserving sessions is also an interesting 
> question, IHMO.
>

That's not answering any of your deeper questions, but the problem here
is that the last code block evaluates a function that produces no
output: it produces a return value though, so try

#+BEGIN_SRC emacs-lisp :results value raw
 (myexptdouble 2 3)
#+END_SRC

-- 
Nick