A few new TODOS: deal with hlines in tables, how do we pass multiple args in R, and some extended wittering about scoping issues in R: basically I want to argue for not abandoning the Sweave-style mode where objects created in code blocks are persisten across different blocks.

org-babel.org

@@ -114,7 +114,7 @@ table, allowing the test suite to be run be evaluation of the table
 and the results to be collected in the same table.
 
 
-* Tasks [20/28]
+* Tasks [20/31]
 
 ** TODO resolve references to other buffers
    This would allow source blocks to call upon tables, source-blocks,
@@ -208,6 +208,70 @@ we should color these blocks differently
 *** TODO refine html exportation
 should use a span class, and should show original source in tool-tip
 
+** TODO allow tables with hline to be passed as args into R
+   This doesn't seem to work at the moment (example below). It would
+   also be nice to have a natural way for the column names of the org
+   table to become the column names of the R data frame, and to have
+   the option to specify that the first column is to be used as row
+   names in R (these must be unique). But this might require a bit of
+   thinking about.
+
+#+TBLNAME: egtable
+| col1 | col2    | col3 |
+|------+---------+------|
+|    1 | 2       |    3 |
+|    4 | schulte |    6 |
+
+#+begin_src R var tabel=egtable
+tabel
+#+end_src
+
+** TODO pass mutliple reference arguments into R
+   Can we do this? I wasn't sure how to supply multiple 'var' header
+   args.
+** TODO Create objects in top level (global) environment in R?
+   At the moment, objects created by computations performed in the
+   code block are evaluated in the scope of the
+   code-block-function-body and therefore disappear when the code
+   block is evaluated {unless you employ some extra trickery like
+   assign('name', object, env=globalenv()) }. I think it will be
+   desirable to also allow for a style wherein objects that are
+   created in one code block persist in the R global environment and
+   can be re-used in a separate block.
+
+   This is what Sweave does, and while I'm not saying we have to be
+   the same as Sweave, it wouldn't be hard for us to provide the same
+   behaviour in this case; if we don't, we risk undeservedly being
+   written off as an oddity by some.
+
+   IOW one aspect of org-babel is that of a sort of functional
+   meta-programming language. This is crazy, in a very good
+   way. Nevertheless, wrt R I think there's going to be a lot of value
+   in providing for a working style in which the objects are stored in
+   the R session, rather than elisp/org buffer. This will be a very
+   familiar working style to lots of people.
+
+   There are no doubt a number of different ways of accomplishing
+   this, the simplest being a hack like adding
+
+#+begin_src R
+for(objname in ls())
+    assign(objname, get(objname), envir=globalenv())
+#+end_src
+
+to the source code block function body. (Maybe wrap it in an on.exit() call).
+
+However this may deserve to be thought about more carefully, perhaps
+with a view to having a uniform approach across languages. E.g. shell
+code blocks have the same semantics at the moment (no persistence of
+variables across code blocks), because the body is evaluated in a new
+bash shell process rather than a running shell. And I guess the same
+is true for python. However, in both these cases, you could imagine
+implementing the alternative in which the body is evaluated in a
+persistent interactive session. It's just that it's particularly
+natural for R, seeing as both ESS and org-babel evaluate commands in a
+single persistent R session.
+
 ** PROPOSED support for passing paths to files between source blocks
 Maybe this should be it's own result type (in addition to scalars and
 vectors).  The reason being that some source-code blocks (for example
@@ -1347,6 +1411,7 @@ x
 |  3.58355906547775 |
 |  3.01563442274226 |
 |   1.7634976849927 |
+
 #+begin_src R var tabel=sandbox_r :results replace
 tabel
 #+end_src