org-mode/library-of-babel.org

51 lines
1.1 KiB
Org Mode
Raw Normal View History

2009-08-04 15:09:08 -04:00
#+title: The Library of Babel
#+SEQ_TODO: TODO PROPOSED | DONE DEFERRED REJECTED
#+OPTIONS: H:3 num:nil toc:t
#+STARTUP: odd hideblocks
#+begin_html
2009-08-04 15:09:08 -04:00
<div id="subtitle">
<p>off-the-shelf functions for data analysis and plotting using <a href="org-babel-worg.html">org-babel</a></p>
</div>
<div id="logo">
<p>
<img src="images/library-of-babel.png" alt="images/tower-of-babel.png" />
<div id="attr"><a href="http://downlode.org/Etext/library_of_babel.html">Full text of the Borges short story</a></div>
</p>
</div>
#+end_html
* Plotting code
Plot column 2 (y axis) against column 1 (x axis). Columns 3 and beyond, if present, are ignored.
Enabling LoB to put results in buffer, and slowly moving towards more unified concept of function calls. Previously LoB calls were not able to produce results in the buffer. These changes go some way to allowing them to do that. [There are still some bugs to deal with]. That meant changing org-babel.el so that there is a notion of the `source block name' for a LoB line, in order to construct a #+resname (currently I've made the name the same as the function call). I'm also slowly moving towards unifying the notion of `function calls' a bit more: I've changed the org-babel-lob-one-liner-regexp so that instead of a monolithic match it now matches first the function name, and second the function arguments in parentheses. org-babel-lob-get-info makes that match, and although it still concatenates them and returns the string, the two elements can be accessed immediately afterwards using match-string. So that situation is very similar to org-babel-get-src-block-name, whose job (in this branch) is also to parse the function *name* and the function *arguments*. In a few places in the code (esp. function names), I think the word `info' should be replaced with `call' or `function call', which I believe more accurately indicates what the `info' is: a function definition, together with bound arguments/references. The function call syntax, i.e. function-name(arg1=ref1), originally introduced for references (and thereby in LoB), and which I'm proposing we use throughout, raises the question of default arguments, and those being over-ridden by supplied arguments, as in e.g. python, and R.
2009-07-10 22:59:10 -04:00
#+srcname: R-plot(data=R-plot-example-data)
#+begin_src R :session *R*
plot(data)
#+end_src
Enabling LoB to put results in buffer, and slowly moving towards more unified concept of function calls. Previously LoB calls were not able to produce results in the buffer. These changes go some way to allowing them to do that. [There are still some bugs to deal with]. That meant changing org-babel.el so that there is a notion of the `source block name' for a LoB line, in order to construct a #+resname (currently I've made the name the same as the function call). I'm also slowly moving towards unifying the notion of `function calls' a bit more: I've changed the org-babel-lob-one-liner-regexp so that instead of a monolithic match it now matches first the function name, and second the function arguments in parentheses. org-babel-lob-get-info makes that match, and although it still concatenates them and returns the string, the two elements can be accessed immediately afterwards using match-string. So that situation is very similar to org-babel-get-src-block-name, whose job (in this branch) is also to parse the function *name* and the function *arguments*. In a few places in the code (esp. function names), I think the word `info' should be replaced with `call' or `function call', which I believe more accurately indicates what the `info' is: a function definition, together with bound arguments/references. The function call syntax, i.e. function-name(arg1=ref1), originally introduced for references (and thereby in LoB), and which I'm proposing we use throughout, raises the question of default arguments, and those being over-ridden by supplied arguments, as in e.g. python, and R.
2009-07-10 22:59:10 -04:00
#+tblname: R-plot-example-data
| 1 | 2 |
| 2 | 4 |
| 3 | 9 |
| 4 | 16 |
| 5 | 25 |
Enabling LoB to put results in buffer, and slowly moving towards more unified concept of function calls. Previously LoB calls were not able to produce results in the buffer. These changes go some way to allowing them to do that. [There are still some bugs to deal with]. That meant changing org-babel.el so that there is a notion of the `source block name' for a LoB line, in order to construct a #+resname (currently I've made the name the same as the function call). I'm also slowly moving towards unifying the notion of `function calls' a bit more: I've changed the org-babel-lob-one-liner-regexp so that instead of a monolithic match it now matches first the function name, and second the function arguments in parentheses. org-babel-lob-get-info makes that match, and although it still concatenates them and returns the string, the two elements can be accessed immediately afterwards using match-string. So that situation is very similar to org-babel-get-src-block-name, whose job (in this branch) is also to parse the function *name* and the function *arguments*. In a few places in the code (esp. function names), I think the word `info' should be replaced with `call' or `function call', which I believe more accurately indicates what the `info' is: a function definition, together with bound arguments/references. The function call syntax, i.e. function-name(arg1=ref1), originally introduced for references (and thereby in LoB), and which I'm proposing we use throughout, raises the question of default arguments, and those being over-ridden by supplied arguments, as in e.g. python, and R.
2009-07-10 22:59:10 -04:00
#+lob: R-plot(data=R-plot-example-data)
#+resname: R-plot(data=R-plot-example-data)
: nil
Enabling LoB to put results in buffer, and slowly moving towards more unified concept of function calls. Previously LoB calls were not able to produce results in the buffer. These changes go some way to allowing them to do that. [There are still some bugs to deal with]. That meant changing org-babel.el so that there is a notion of the `source block name' for a LoB line, in order to construct a #+resname (currently I've made the name the same as the function call). I'm also slowly moving towards unifying the notion of `function calls' a bit more: I've changed the org-babel-lob-one-liner-regexp so that instead of a monolithic match it now matches first the function name, and second the function arguments in parentheses. org-babel-lob-get-info makes that match, and although it still concatenates them and returns the string, the two elements can be accessed immediately afterwards using match-string. So that situation is very similar to org-babel-get-src-block-name, whose job (in this branch) is also to parse the function *name* and the function *arguments*. In a few places in the code (esp. function names), I think the word `info' should be replaced with `call' or `function call', which I believe more accurately indicates what the `info' is: a function definition, together with bound arguments/references. The function call syntax, i.e. function-name(arg1=ref1), originally introduced for references (and thereby in LoB), and which I'm proposing we use throughout, raises the question of default arguments, and those being over-ridden by supplied arguments, as in e.g. python, and R.
2009-07-10 22:59:10 -04:00
* Etc
#+srcname: python-identity(a=1)
Enabling LoB to put results in buffer, and slowly moving towards more unified concept of function calls. Previously LoB calls were not able to produce results in the buffer. These changes go some way to allowing them to do that. [There are still some bugs to deal with]. That meant changing org-babel.el so that there is a notion of the `source block name' for a LoB line, in order to construct a #+resname (currently I've made the name the same as the function call). I'm also slowly moving towards unifying the notion of `function calls' a bit more: I've changed the org-babel-lob-one-liner-regexp so that instead of a monolithic match it now matches first the function name, and second the function arguments in parentheses. org-babel-lob-get-info makes that match, and although it still concatenates them and returns the string, the two elements can be accessed immediately afterwards using match-string. So that situation is very similar to org-babel-get-src-block-name, whose job (in this branch) is also to parse the function *name* and the function *arguments*. In a few places in the code (esp. function names), I think the word `info' should be replaced with `call' or `function call', which I believe more accurately indicates what the `info' is: a function definition, together with bound arguments/references. The function call syntax, i.e. function-name(arg1=ref1), originally introduced for references (and thereby in LoB), and which I'm proposing we use throughout, raises the question of default arguments, and those being over-ridden by supplied arguments, as in e.g. python, and R.
2009-07-10 22:59:10 -04:00
#+begin_src python
a
#+end_src
#+srcname: python-add(a=1, b=2)
#+begin_src python
a + b
#+end_src