Re: [Orgmode] Possible Calc support for Org-Babel?

[Eric Schulte]

Alright,

I've just pushed up support for variables.  The following should all
work as expected (or at least as I would expect them to).  Note that
most all of these blocks would have an effect on the calc stack.  I
think the next step would be to allow different sessions to specify
different stacks.

** playing with calc support
#+begin_src emacs-lisp :results silent
  (require 'ob-calc)
#+end_src

#+begin_src calc :var some=8
  some
  some
  '*
  1
  '+
#+end_src

#+results:
: 65

#+begin_src calc
  2*(8+8)
#+end_src

#+results:
: 32

#+begin_src calc
  2*e
#+end_src

#+results:
: 5.43656365692

#+begin_src calc :var something=9
  2*something
#+end_src

#+results:
: 18

There are very likely some bugs, and as always I'm eager for a calc
power user to show me the light of how this support could be make more
"calc idiomatic".

Cheers -- Eric

Eric S Fraga <address@hidden> writes:

> Forgot to CC the list et al.
>
> "Eric Schulte" <address@hidden> writes:
>
>> Eric S Fraga <address@hidden> writes:
>
> [...]
>
>>> I now wonder if it would be worthwhile discussing the choices you have
>>> made regarding stack versus algebraic evaluation.  I would rather have
>>> the quote mean an algebraic expression, just from the simple reason that
>>> these will be longer than stack operations and so the overhead of a
>>> quote is smaller as a percentage of keystrokes...
>>>
>>
>> Hmm, one point against prefixing the algebraic expressions is that they
>> would be more likely to be used by themselves in an inline code block.
>
> Yes, I guess so.  My initial thoughts were that we have plenty of
> algebraic languages available already through babel (octave, R, python,
> ...) so why not support a stack based one more directly.   However, the
> real benefit of calc is that it is *emacs* and not external!  Algebraic
> is more natural to most people so making it easy for them to express
> themselves makes sense.