Merge branch 'session' of git@github.com:eschulte/org-babel into session

lisp/org-babel-R.el

@@ -57,16 +57,14 @@ R process in `org-babel-R-buffer'."
   (unless org-babel-R-buffer (error "No active R buffer"))
   (org-babel-R-input-command
    (if (listp value)
-       (let ((transition-file (make-temp-file "org-babel-R-import"))
-	     has-header)
+       (let ((transition-file (make-temp-file "org-babel-R-import")))
 	 ;; ensure VALUE has an orgtbl structure (depth of at least 2)
 	 (unless (listp (car value)) (setq value (list value)))
-	 (setq has-header (and (symbolp (cadr value)) (equal (cadr value) 'hline)))
 	 (with-temp-file transition-file
 	   (insert (orgtbl-to-tsv value '(:fmt org-babel-R-quote-tsv-field)))
 	   (insert "\n"))
-	 (format "%s <- read.table(\"%s\", header=%s, sep=\"\\t\", as.is=TRUE)"
-		 name transition-file (if has-header "TRUE" "FALSE")))
+	 (format "%s <- read.table(\"%s\", header=FALSE, sep=\"\\t\", as.is=TRUE)"
+		 name transition-file))
      (format "%s <- %s" name (org-babel-R-quote-tsv-field value)))))
 
 (defun org-babel-R-last-value-as-elisp ()
@@ -93,27 +91,6 @@ R process in `org-babel-R-buffer'."
             (car result))
         result))))
 
-(defun org-babel-R-set-header-row (table)
-  "Check whether the table appears to have (a) genuine
-user-supplied column names, or (b) default column names added
-automatically by R. In case (a), maintain the first row of the
-table as a header row and insert an hline. In case (b), remove
-the first row and return the org table without an hline."
-  (if (or (string-equal (caar table) "V1")
-	  (string-equal (caar table) "x"))
-
-      ;; write.table(1, col.names=TRUE) makes a colname called "x". I
-      ;; think shows that this approach is too much of a hack: we
-      ;; can't take some totally different action just because we see
-      ;; an "x" there that might or might not be a automatic name.
-
-      ;; The first row looks like it contains default column names
-      ;; added by R. This condition could be improved so that it
-      ;; checks whether the first row is ("V1" "V2" ... "V$n") where
-      ;; $n is the number of columns.
-      (cdr table)
-    (cons (car table) (cons 'hline (cdr table)))))
-
 (defun org-babel-R-read (cell)
   "Strip nested \"s from around strings in exported R values."
   (org-babel-read (or (and (stringp cell)
@@ -127,8 +104,6 @@ the first row and return the org table without an hline."
 
 (defun org-babel-R-initiate-R-buffer ()
   "If there is not a current R process then create one."
-  ;; DED: Ideally I think we should use ESS mechanisms for this sort
-  ;; of thing. See ess-force-buffer-current.
   (unless (and (buffer-live-p org-babel-R-buffer) (get-buffer org-babel-R-buffer))
     (save-excursion
       (R)

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 [22/37]
+* Tasks [22/38]
 ** TODO Create objects in top level (global) environment [0/5]
 *sessions*
 
@@ -332,6 +332,80 @@ level of the console environment will be set *everywhere* inside
 emacs.  For this reason I think that it doesn't make any sense to
 worry about session support for emacs-lisp.
 
+*** Further thoughts on 'scripting' vs. functional approaches
+
+    These are just thoughts, I don't know how sure I am about this.
+    And again, perhaps I'm not saying anything very radical, just that
+    it would be nice to have some options supporting things like
+    receiving text output in the org buffer.
+
+    I can see that you've already gone some way down the road towards
+    the 'last value' approach, so sorry if my comments come rather
+    late. I am concerned that we are not giving sufficient attention
+    to stdout / the text that is returned by the interpreters. In
+    contrast, many of our potential users will be accustomed to a
+    'scripting' approach, where they are outputting text at various
+    points in the code block, not just at the end. I am leaning
+    towards thinking that we should have 2 modes of evaluation:
+    'script' mode, and 'functional' mode.
+
+    In script mode, evaluation of a code block would result in *all*
+    text output from that code block appearing as output in the org
+    buffer, presumably as an #+begin_example...#+end_example. There
+    could be an :echo option controlling whether the input commands
+    also appear in the output. [This is like Sweave].
+
+    In functional mode, the *result* of the code block is available as
+    an elisp object, and may appear in the org buffer as an org
+    table/string, via the mechanisms you have developed already.
+
+    One thing I'm wondering about is whether, in script mode, there
+    simply should not be a return value. Perhaps this is not so
+    different from what exists: script mode would be new, and what
+    exists currently would be functional mode.
+
+    I think it's likely that, while code evaluation will be exciting
+    to people, a large majority of our users in a large majority of
+    their usage will not attempt to actually use the return value from
+    a source code block in any meaningful way. In that case, it seems
+    rather restrictive to only allow them to see output from the end
+    of the code block.
+
+    Instead I think the most accessible way to introduce org-babel to
+    people, at least while they are learning it, is as an immensely
+    powerful environment in which to embed their 'scripts', which now
+    also allows them to 'run' their 'scripts'. Especially as such
+    people are likely to be the least capable of the user-base, a
+    possible design-rule would be to make the scripting style of usage
+    easy (default?), perhaps requiring a special option to enable a
+    functional style. Those who will use the functional style won't
+    have a problem understanding what's going on, whereas the 'skript
+    kiddies' might not even know the syntax for defining a function in
+    their language of choice. And of course we can allow the user to
+    set a variable in their .emacs controlling the preference, so that
+    functional users are not inconveniennced by having to provide
+    header args the whole time.
+
+    Please don't get the impression that I am down-valuing the
+    functional style of org-babel. I am constantly horrified at the
+    messy 'scripts' that my colleagues produce in perl or R or
+    whatever! Nevertheless that seems to be how a lot of people work.
+    
+    I think you were leaning towards the last-value approach because
+    it offered the possibility of unified code supporting both the
+    single evaluation environment and the functional style. If you
+    agree with any of the above then perhaps it will impact upon this
+    and mean that the code in the two branches has to differ a bit. In
+    that case, functional mode could perhaps after all evaluate each
+    code block in its own environment, thus (re)approaching 'true'
+    functional programming (side-effects are hard to achieve).
+
+#+begin_src sh
+ls > files
+echo "There are `wc -l files` files in this directory"
+
+#+end_src
+
 *** TODO rework all source codes to use inferior-processes-buffers
 
 this will involve...
@@ -510,6 +584,11 @@ waiting for guidance from those more familiar with yasnippets
    - [[file:lisp/org-babel-ref.el::TODO%20allow%20searching%20for%20names%20in%20other%20buffers][org-babel-ref.el:searching-in-other-buffers]]
    - [[file:lisp/org-babel.el::defun%20org-babel%20find%20named%20result%20name][org-babel.el#org-babel-find-named-result]]
 
+** TODO figure out how to handle errors during evaluation
+   R has a try function, with error handling, along the lines of
+   python. I bet ruby does too. Maybe more of an issue for functional
+   style; in my proposed scripting style the error just gets dumped to
+   the org buffer and the user is thus alerted.
 ** TODO figure out how to handle graphic output
 This is listed under [[* graphical output][graphical output]] in out objectives.