evaluation context in call statements

evaluation context in call statements

[Rick Frankel]

FThe arguments to a `#+call' line are evaluated in the context of the
called block and not the calling block. This seems like a bug to me. For
example, in the following i would expect the `call' to return "Call" and
not "Source" as the results:

╭────
│ * Source
│ #+name: message
│ #+BEGIN_SRC elisp :var m="foo"
│   m
│ #+END_SRC
│
│  #+RESULTS: message
│  : foo
│
│ * Call
│ #+call: message(m=(nth 4 (org-heading-components)))
│
│ #+RESULTS: message(m=(nth 4 (org-heading-components)))
│ : Source
╰────

is there any way to reference the current context in a `call' line?

rick

Re: evaluation context in call statements

[Achim Gratz]

Rick Frankel writes:
> The arguments to a `#+call' line are evaluated in the context of the
> called block and not the calling block. This seems like a bug to me. For
> example, in the following i would expect the `call' to return "Call" and
> not "Source" as the results:

Tody's your lucky day because Eric just fixed this.  There's a bug with
finding the #+RESULTS line though:

--8<---------------cut here---------------start------------->8---
* Babel LOC
** Source
 #+name: message
 #+BEGIN_SRC elisp :var m="foo"
   m
 #+END_SRC

  #+RESULTS: message
  : foo

** Call 1
 #+call: message(m=(nth 4 (org-heading-components)))

 #+RESULTS: message(m=(nth 4 (org-heading-components)))
 : Call 2

** Call 2
 #+call: message(m=(nth 4 (org-heading-components)))
--8<---------------cut here---------------end--------------->8---

Executing Call#2 will update the #+RESULTS for Call#1 (or actually the
first matching #+RESULTS cookie in the whole document).  I'd think it
should also start looking for the results line from the point of call.
I don't really get why it does this, maybe Eric knows where to look.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: evaluation context in call statements

[Achim Gratz]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

Achim Gratz writes:
> Rick Frankel writes:

Your lucky day is becoming a streak.

> Executing Call#2 will update the #+RESULTS for Call#1 (or actually the
> first matching #+RESULTS cookie in the whole document).  I'd think it
> should also start looking for the results line from the point of call.
> I don't really get why it does this, maybe Eric knows where to look.

I'd think this should fix it.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ob-core-insert-results-at-the-point-of-call.patch --]
[-- Type: text/x-patch, Size: 1775 bytes --]

From 945d7d25a63077bae18c656768939f292b52bb44 Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Tue, 25 Jun 2013 21:51:07 +0200
Subject: [PATCH] ob-core: insert results at the point of call

* lisp/ob-core.el (org-babel-execute-src-block): Ensure that head is
  set to location of call if it is known.  Pass through head to
  `org-babel-find-named-result' so that it doesn't search from the
  beginning of the file.
---
 lisp/ob-core.el | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 4115912..36f42e1 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -662,8 +662,8 @@ (defun org-babel-execute-src-block (&optional arg info params)
 			(when (cdr (assoc :file params))
 			  (setq result-params
 				(remove "file" result-params)))))
-		    (org-babel-insert-result
-		     result result-params info new-hash indent lang))
+		      (org-babel-insert-result
+		       result result-params info new-hash indent lang))
                   (run-hooks 'org-babel-after-execute-hook)
 		  result)
 	      (setq call-process-region
@@ -1839,7 +1839,11 @@ (defun org-babel-where-is-src-block-result (&optional insert info hash indent)
 	  ;; - return t if it is found, else return nil
 	  ;; - if it does not need to be rebuilt, then don't set end
 	  ;; - if it does need to be rebuilt then do set end
-	  name (setq beg (org-babel-find-named-result name))
+	  name (setq beg (org-babel-find-named-result
+			  name
+			  (or org-babel-current-src-block-location
+			      (nth 6 info)
+			      (org-babel-where-is-src-block-head))))
 	  (prog1 beg
 	    (when (and hash (not (string= hash (match-string 5))))
 	      (goto-char beg) (setq end beg) ;; beginning of result
-- 
1.8.3.1


[-- Attachment #3: Type: text/plain, Size: 187 bytes --]



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: evaluation context in call statements

[Achim Gratz]

Achim Gratz writes:
> I'd think this should fix it.

Please discard the first hunk of this patch.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: evaluation context in call statements

[Michael Brand]

Hi Achim

On Tue, Jun 25, 2013 at 9:53 PM, Achim Gratz <Stromeko@nexgo.de> wrote:
> Achim Gratz writes:
>> Executing Call#2 will update the #+RESULTS for Call#1 (or actually the
>> first matching #+RESULTS cookie in the whole document).  I'd think it
>> should also start looking for the results line from the point of call.
>> I don't really get why it does this, maybe Eric knows where to look.
>
> I'd think this should fix it.

Is it a bug?

I also noticed this when I was writing an ERT. First it confused me
but then I thought that this is intended to make it possible to
have #+BEGIN_SRC and #+RESULT at independent locations, possibly in
reverse order. For how to address several similar calls to different
results see my ERT patch here
http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73655
and the messages before. I used :session for emacs-lisp and a
workaround with :var dummy_name for Babel languages that do not
support :session like shell.

Michael

Re: evaluation context in call statements

[Achim Gratz]

Michael Brand writes:
> Is it a bug?

I think so, but Eric has the last word on this.  The results should come
after the call, but the current implementation would look for the
results line from the beginning of the buffer.

> I also noticed this when I was writing an ERT. First it confused me
> but then I thought that this is intended to make it possible to
> have #+BEGIN_SRC and #+RESULT at independent locations, possibly in
> reverse order.

I can't see how it would be much more difficult to have a #+CALL where
you want the result (independently of where the source block is), but it
seems pretty limiting to allow only a single result.

> For how to address several similar calls to different results see my
> ERT patch here
> http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73655 and the
> messages before. I used :session for emacs-lisp and a workaround with
> :var dummy_name for Babel languages that do not support :session like
> shell.

I didn't get what you were trying to do there, but it's pretty obvious
now.

Anyway, more testing shows my patch will prefer the results line after
the call, but if you then insert another call before that (without an
existing result) the result from the now second call will still be
clobbered, so there needs to be some more fixing by limiting the search
to not extend across other calls or source blocks.  Or this really is a
feature, although I don't really see much use for it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: evaluation context in call statements

[Achim Gratz]

Achim Gratz writes:
> Anyway, more testing shows my patch will prefer the results line after
> the call, but if you then insert another call before that (without an
> existing result) the result from the now second call will still be
> clobbered, so there needs to be some more fixing by limiting the search
> to not extend across other calls or source blocks.  Or this really is a
> feature, although I don't really see much use for it.

If this feature turns out to be useful, how about a :target header
argument to specify a named result block?  Then it would also be
possible to eliminate those rather unsightly appendices.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: evaluation context in call statements

[Eric Schulte]

>> Is it a bug?
>
> I think so, but Eric has the last word on this.  The results should come
> after the call, but the current implementation would look for the
> results line from the beginning of the buffer.
>

The current behavior is the expected behavior and is not a bug.  That
said, I don't believe the current behavior is necessarily the best
behavior, rather it was the obvious choice at the time of implementation
and there has never been a successful push to change it.

I think we could be well served by discussing how people use call lines,
how they would use call lines (if this behavior changed), and what
behavior would best support these existing and potential use cases.

In defense of the existing behavior, I don't see the benefit of calling
a code block with the same arguments from multiple locations and
subsequently littering a file with multiple identical results blocks.

If we do want to change this behavior it would be nice to check the
email list archives to see if/when the existing behavior has been
defended in the past.

> > Anyway, more testing shows my patch will prefer the results line after
> > the call, but if you then insert another call before that (without an
> > existing result) the result from the now second call will still be
> > clobbered, so there needs to be some more fixing by limiting the search
> > to not extend across other calls or source blocks.  Or this really is a
> > feature, although I don't really see much use for it.

> If this feature turns out to be useful, how about a :target header
> argument to specify a named result block?  Then it would also be
> possible to eliminate those rather unsightly appendices.

My only thought about a :target header argument is that it would need to
be implemented for other types of code blocks as well, which could lead
to very confusing behavior if we have a named code block with a :target
header argument which differs from the name.

Also, if the target is referenced, would the #+call line be re-run?

My vote is for adding #+name support to call lines, and then handling
their results in the same manner as code block results.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: evaluation context in call statements

[Achim Gratz]

Eric Schulte writes:
> In defense of the existing behavior, I don't see the benefit of calling
> a code block with the same arguments from multiple locations and
> subsequently littering a file with multiple identical results blocks.

I agree that this didn't make all that much sense in the past, but with
property evaluation and elisp argument evaluation now anchored to the
point of call, the hierarchical position of the call could and (as the
test case from Rick) will be used to distinguish between invocations
with the same arguments.  Since the current way to find the results
doesn't know anything about this, it will generally not do the right
thing anymore.  Note that calls using a session had that property all
the time: multiple calls with the same arguments into the same session
are useful, but Babel would only keep the last result.

> If we do want to change this behavior it would be nice to check the
> email list archives to see if/when the existing behavior has been
> defended in the past.

If you'd happen to know when that was introduced?

> My only thought about a :target header argument is that it would need to
> be implemented for other types of code blocks as well, which could lead
> to very confusing behavior if we have a named code block with a :target
> header argument which differs from the name.

Oh yes, the specification of that would be interesting.  I'll try to see
how this "beam the result anywhere" functionality sprang into existence
and what the intended use case was (I expect something to do with
sessions).

My current suggestion is however to limit the results block search to
the same subtree and stop searching at later #+CALL and #+BEGIN_SRC
line.  We could make this conditional on a :[no]clobber argument to keep
compatibility with the current behaviour (clobbering the first result
would be the current and perhaps default behaviour).

> Also, if the target is referenced, would the #+call line be re-run?

Not any more that a reference to a named result would re-run its source
block.

> My vote is for adding #+name support to call lines, and then handling
> their results in the same manner as code block results.

I'm not sure what this would entail other than replacing the call with
its arguments with the name of the call in the results line.  But yes,
that'd be a step forward, although you'd have to be careful when copying
calls.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: evaluation context in call statements

[Michael Brand]

Hi Eric

On Wed, Jun 26, 2013 at 12:41 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
> I think we could be well served by discussing how people use call lines,
> how they would use call lines (if this behavior changed), and what
> behavior would best support these existing and potential use cases.

You did not yet answer to what I asked you about more than one call
with the same arguments:
http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73547

> In defense of the existing behavior, I don't see the benefit of calling
> a code block with the same arguments from multiple locations and
> subsequently littering a file with multiple identical results blocks.

Such result blocks do not have to be necessarily identical. What would
you suggest for these examples?:

1) It could be just me feeling like to be on the playground:
   -------------------------------------------------------------------
   #+NAME: i_am_curious_how_this_works
   #+BEGIN_SRC emacs-lisp
     (format "%s" org-babel-current-src-block-location)
   #+END_SRC

   #+CALL: i_am_curious_how_this_works()

   #+RESULTS: i_am_curious_how_this_works()
   : #<marker at 124 in tmp.org>

   #+CALL: i_am_curious_how_this_works()

   (Here I expect to see the result "#<marker at 235 in tmp.org>".)
   -------------------------------------------------------------------

2) My use case mentioned at the beginning of this message.

Michael

Re: evaluation context in call statements

[Rick Frankel]

On 2013-06-26 02:29, Achim Gratz wrote:
> Eric Schulte writes:
> In defense of the existing behavior, I don't see the benefit of calling
> a code block with the same arguments from multiple locations and
> subsequently littering a file with multiple identical results blocks.
> 
> I agree that this didn't make all that much sense in the past, but with
> property evaluation and elisp argument evaluation now anchored to the
> point of call, the hierarchical position of the call could and (as the
> test case from Rick) will be used to distinguish between invocations
> with the same arguments.  Since the current way to find the results
> doesn't know anything about this, it will generally not do the right
> thing anymore.  Note that calls using a session had that property all
> the time: multiple calls with the same arguments into the same session
> are useful, but Babel would only keep the last result.

Agreed. The only way to know that the arguments are the "same" is to
evaluated them :).

> My only thought about a :target header argument is that it would need 
> to
> be implemented for other types of code blocks as well, which could lead
> to very confusing behavior if we have a named code block with a :target
> header argument which differs from the name.
> 
> Oh yes, the specification of that would be interesting.  I'll try to 
> see
> how this "beam the result anywhere" functionality sprang into existence
> and what the intended use case was (I expect something to do with
> sessions).

I believe the ability to replace named results anywhere was added by
Nicolas in commit 2f2a80fe (quick look at ob-core w/ vc-annotate).

> My current suggestion is however to limit the results block search to
> the same subtree and stop searching at later #+CALL and #+BEGIN_SRC
> line.  We could make this conditional on a :[no]clobber argument to 
> keep
> compatibility with the current behaviour (clobbering the first result
> would be the current and perhaps default behaviour).

These search bounds make sense, but i think this should be the
default behavior. I don't see the current behavior as making
sense---at least to me. At the time (late 2012) I found Nicolases
changes (named results blocks, attributes and captions on the results
block and not the source, etc) confusing. I still find it odd that you
need to evaluate a source block before you can e.g, add a caption or
attributes to the results (previous behavior was that header arguments
on the source block were used for the results in exporting.)

Also, i think a new value for :replace ("original"?) would make more
sense than a new :clobber option.

> My vote is for adding #+name support to call lines, and then handling
> their results in the same manner as code block results.
> 
> I'm not sure what this would entail other than replacing the call with
> its arguments with the name of the call in the results line.  But yes,
> that'd be a step forward, although you'd have to be careful when 
> copying
> calls.

It seems inconsistent to add #+name support to call lines but not the 
other
block modifiers (#+header :var ..., etc). I think call lines are a
special case, so would be ok with the new :target option.

rick

Re: evaluation context in call statements

[Eric Schulte]

Michael Brand <michael.ch.brand@gmail.com> writes:

> Hi Eric
>
> On Wed, Jun 26, 2013 at 12:41 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> I think we could be well served by discussing how people use call lines,
>> how they would use call lines (if this behavior changed), and what
>> behavior would best support these existing and potential use cases.
>
> You did not yet answer to what I asked you about more than one call
> with the same arguments:
> http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73547
>

They will overwrite eachother's results.  We are currently discussing
alternatives which would change this behavior.

>
>> In defense of the existing behavior, I don't see the benefit of calling
>> a code block with the same arguments from multiple locations and
>> subsequently littering a file with multiple identical results blocks.
>
> Such result blocks do not have to be necessarily identical. What would
> you suggest for these examples?:
>
> 1) It could be just me feeling like to be on the playground:
>    -------------------------------------------------------------------
>    #+NAME: i_am_curious_how_this_works
>    #+BEGIN_SRC emacs-lisp
>      (format "%s" org-babel-current-src-block-location)
>    #+END_SRC
>
>    #+CALL: i_am_curious_how_this_works()
>
>    #+RESULTS: i_am_curious_how_this_works()
>    : #<marker at 124 in tmp.org>
>    #+CALL: i_am_curious_how_this_works()
>
>    (Here I expect to see the result "#<marker at 235 in tmp.org>".)
>    -------------------------------------------------------------------
>

This works as expected.  Depending on the call line executed, I get
different points in the second results.

>
> 2) My use case mentioned at the beginning of this message.
>

Currently if you want have separate results for call lines with the same
variables you will need to use a dummy variable.  I'd suggest an OS
variable if you are running them on different operating systems.

>
> Michael

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: evaluation context in call statements

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

>> My vote is for adding #+name support to call lines, and then handling
>> their results in the same manner as code block results.

Achim Gratz <Stromeko@nexgo.de> writes:
> I'm not sure what this would entail other than replacing the call with
> its arguments with the name of the call in the results line.  But yes,
> that'd be a step forward, although you'd have to be careful when copying
> calls.
>

This could work exactly as named source blocks work.  E.g.,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: named-calls.org --]
[-- Type: text/x-org, Size: 432 bytes --]

Unnamed code block.

#+begin_src emacs-lisp
  'bar
#+end_src

#+RESULTS:
: bar

Named code block.

#+name: foo-block
#+begin_src emacs-lisp
  'foo
#+end_src

can have text between itself and its results

#+RESULTS: foo-block
: foo

Unnamed call line.

#+call: foo-block()

#+RESULTS: foo-block()
: foo

Named call line.

#+name: foo-call
#+call: foo-block()

Can have text between itself and its results.

#+RESULTS: foo-call
: foo

[-- Attachment #3: Type: text/plain, Size: 2311 bytes --]


Rick Frankel <rick@rickster.com> writes:
> It seems inconsistent to add #+name support to call lines but not the
> other block modifiers (#+header :var ..., etc). I think call lines are
> a special case, so would be ok with the new :target option.

See above.  This is not inconsistent, it is equivalent with how names
and code block already work, which means it is less for new users to
learn and old users to keep track of.  Also, the existing code block
results handling has not caused much confusion, and seems to be powerful
enough to deal with every use case.

Achim Gratz <Stromeko@nexgo.de> and Rick Frankel <rick@rickster.com> write:
>> My current suggestion is however to limit the results block search to
>> the same subtree and stop searching at later #+CALL and #+BEGIN_SRC
>> line.  We could make this conditional on a :[no]clobber argument to
>> keep compatibility with the current behaviour (clobbering the first
>> result would be the current and perhaps default behaviour).
>
> These search bounds make sense, but i think this should be the
> default behavior. I don't see the current behavior as making
> sense---at least to me.

I agree that the current behavior is confusing, but I don't like this
suggestion.  I expect people will be mystified when calls replace
results in the same subtree and don't replace blocks elsewhere in the
same Org-mode file.  No other parts of Org-mode's code block support
work this way.

> At the time (late 2012) I found Nicolases changes (named results
> blocks, attributes and captions on the results block and not the
> source, etc) confusing. I still find it odd that you need to evaluate
> a source block before you can e.g, add a caption or attributes to the
> results (previous behavior was that header arguments on the source
> block were used for the results in exporting.)
>

I think this behavior works well and I don't think it will change.  I
see how it could be nice to automatically apply attributes (e.g.,
captions, labels etc...) of a code block to that blocks results, but
then what if I want to export the code block body and not the results,
what if I want to export both.  I think Nicolas was right to unify,
simplify and clarify the Org-mode attribute semantics.

Thanks for the feedback.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: evaluation context in call statements

[Nicolas Goaziou]

Hello,

Rick Frankel <rick@rickster.com> writes:

> At the time (late 2012) I found Nicolases changes (named results
> blocks, attributes and captions on the results block and not the
> source, etc) confusing. I still find it odd that you need to evaluate
> a source block before you can e.g, add a caption or attributes to the
> results (previous behavior was that header arguments on the source
> block were used for the results in exporting.)

But you couldn't provide different captions (or attributes) to source
code and results (or no caption/attribute to one of them only).

If you think about it, it's not very odd that captions and attributes
apply to the text located just below, instead of some remote or yet to
be generated piece of text.


Regards,

-- 
Nicolas Goaziou

Re: evaluation context in call statements

[Rick Frankel]

Nicolas-

On 2013-06-26 11:13, Nicolas Goaziou wrote:
> 
> Rick Frankel <rick@rickster.com> writes:
> 
> At the time (late 2012) I found Nicolases changes (named results
> blocks, attributes and captions on the results block and not the
> source, etc) confusing. I still find it odd that you need to evaluate
> a source block before you can e.g, add a caption or attributes to the
> results (previous behavior was that header arguments on the source
> block were used for the results in exporting.)
> 
> But you couldn't provide different captions (or attributes) to source
> code and results (or no caption/attribute to one of them only).
> 
> If you think about it, it's not very odd that captions and attributes
> apply to the text located just below, instead of some remote or yet to
> be generated piece of text.
> 

I agree now (as i did then), with the functionality and understand why
and how it works, but i still find having to execute a source block
before being able to attribute the results counter-intuitive (as have
others). It's kind of like having to wait for the house to be built
before you can decide/buy the paint to finish it: ) But I also, don't
see any better way to provide the useful functionality of being able
to attribute the code block and results separately --- although in my
normal use cases, i don't usually export both code and results
together.

rick

Re: evaluation context in call statements

[Eric Schulte]

Rick Frankel <rick@rickster.com> writes:

> Nicolas-
>
> On 2013-06-26 11:13, Nicolas Goaziou wrote:
>>
>> Rick Frankel <rick@rickster.com> writes:
>>
>> At the time (late 2012) I found Nicolases changes (named results
>> blocks, attributes and captions on the results block and not the
>> source, etc) confusing. I still find it odd that you need to evaluate
>> a source block before you can e.g, add a caption or attributes to the
>> results (previous behavior was that header arguments on the source
>> block were used for the results in exporting.)
>>
>> But you couldn't provide different captions (or attributes) to source
>> code and results (or no caption/attribute to one of them only).
>>
>> If you think about it, it's not very odd that captions and attributes
>> apply to the text located just below, instead of some remote or yet to
>> be generated piece of text.
>>
>
> I agree now (as i did then), with the functionality and understand why
> and how it works, but i still find having to execute a source block
> before being able to attribute the results counter-intuitive (as have
> others).

You are free to type a #+RESULTS: line manually.

If you use yasnippets you could define a snippet for a named code block
which inserts the #+RESULTS line concurrently with the code block.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: evaluation context in call statements

[Michael Brand]

Hi Eric

On Wed, Jun 26, 2013 at 4:54 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73547
>
> They will overwrite eachother's results.

I do not understand. In order to avoid that they will overwrite
eachother's results I added `dummy_name="osx"' and `dummy_name="gnu"'
to the call arguments. What did you mean?

> We are currently discussing
> alternatives which would change this behavior.

My suggestions to this discussion have been two alternatives that
already work now and that I already used, see my use case
"unicode_normal_form_c" and my patch with the ERT in the other thread
mentioned above:
1) use :session where supported like for emacs-lisp source blocks
2) use ":var dummy_name" as a workaround where :session is not
   supported like for shell source blocks

>>    -------------------------------------------------------------------
>>    #+NAME: i_am_curious_how_this_works
>>    #+BEGIN_SRC emacs-lisp
>>      (format "%s" org-babel-current-src-block-location)
>>    #+END_SRC
>>
>>    #+CALL: i_am_curious_how_this_works()
>>
>>    #+RESULTS: i_am_curious_how_this_works()
>>    : #<marker at 124 in tmp.org>
>>    #+CALL: i_am_curious_how_this_works()
>>
>>    (Here I expect to see the result "#<marker at 235 in tmp.org>".)
>>    -------------------------------------------------------------------
>
> This works as expected.  Depending on the call line executed, I get
> different points in the second results.

I am sorry, I wanted to say that I want to do something like
(note: not current behavior)

-------------------------------------------------------------------
#+NAME: i_am_curious_how_this_works
#+BEGIN_SRC emacs-lisp
  (format "%s" org-babel-current-src-block-location)
#+END_SRC

#+CALL: i_am_curious_how_this_works()

#+RESULTS: i_am_curious_how_this_works()
: #<marker at 124 in tmp.org>

#+CALL: i_am_curious_how_this_works()

#+RESULTS: i_am_curious_how_this_works()
: #<marker at 236 in tmp.org>

-------------------------------------------------------------------

and would like the yet to be defined solution in discussion here to
make also this possible, together with the appropriate change if
necessary to the example given above.

Currently working alternative with the change to use ":session":

-------------------------------------------------------------------
#+NAME: i_am_curious_how_this_works
#+BEGIN_SRC emacs-lisp
  (format "%s" org-babel-current-src-block-location)
#+END_SRC

#+CALL: i_am_curious_how_this_works[:session upper]()

#+RESULTS: i_am_curious_how_this_works[:session upper]()
: #<marker at 124 in tmp.org>

#+CALL: i_am_curious_how_this_works[:session lower]()

#+RESULTS: i_am_curious_how_this_works[:session lower]()
: #<marker at 267 in tmp.org>

-------------------------------------------------------------------

Currently working alternative with the change to use
":var dummy_name":

-------------------------------------------------------------------
#+NAME: i_am_curious_how_this_works
#+BEGIN_SRC emacs-lisp :var dummy_name=""
  (format "%s" org-babel-current-src-block-location)
#+END_SRC

#+CALL: i_am_curious_how_this_works(dummy_name="upper")

#+RESULTS: i_am_curious_how_this_works(dummy_name="upper")
: #<marker at 143 in tmp.org>

#+CALL: i_am_curious_how_this_works(dummy_name="lower")

#+RESULTS: i_am_curious_how_this_works(dummy_name="lower")
: #<marker at 290 in tmp.org>

-------------------------------------------------------------------

> Currently if you want have separate results for call lines with the same
> variables you will need to use a dummy variable.

Ok, this answers one of my questions in the other thread and confirms
my expectation. Does it mean that my patch with the ERT as of
2013-06-19 from the other thread is ok for now and can be applied
just to reflect what is currently supported? Or should I change
something else in the patch?

Michael

Re: evaluation context in call statements

[Eric Schulte]

> I am sorry, I wanted to say that I want to do something like
> (note: not current behavior)
>
> -------------------------------------------------------------------
> #+NAME: i_am_curious_how_this_works
> #+BEGIN_SRC emacs-lisp
>   (format "%s" org-babel-current-src-block-location)
> #+END_SRC
>
> #+CALL: i_am_curious_how_this_works()
>
> #+RESULTS: i_am_curious_how_this_works()
> : #<marker at 124 in tmp.org>
> #+CALL: i_am_curious_how_this_works()
>
> #+RESULTS: i_am_curious_how_this_works()
> : #<marker at 236 in tmp.org>
>
> -------------------------------------------------------------------
>
> and would like the yet to be defined solution in discussion here to
> make also this possible,

If we do add #+names to call lines, and have them adopt the existing
code block result behavior, then the above will work without
modification.

[...]
>> Currently if you want have separate results for call lines with the same
>> variables you will need to use a dummy variable.
>
> Ok, this answers one of my questions in the other thread and confirms
> my expectation. Does it mean that my patch with the ERT as of
> 2013-06-19 from the other thread is ok for now and can be applied just
> to reflect what is currently supported? Or should I change something
> else in the patch?
>

Yes, I've just applied this patch.  Sorry for the delay.

Thanks,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: evaluation context in call statements

[Achim Gratz]

Eric Schulte writes:
>>> My vote is for adding #+name support to call lines, and then handling
>>> their results in the same manner as code block results.
>
> Achim Gratz <Stromeko@nexgo.de> writes:
>> I'm not sure what this would entail other than replacing the call with
>> its arguments with the name of the call in the results line.  But yes,
>> that'd be a step forward, although you'd have to be careful when copying
>> calls.
>>
>
> This could work exactly as named source blocks work.  E.g.,
[...]

I see.  The problem then really is that #+CALL lines are currently
"implicitly named" by copying their arguments to the results line.  If
explicit naming is allowed, this implicit naming should go away or at
least not be the default, IMHO.

> I agree that the current behavior is confusing, but I don't like this
> suggestion.  I expect people will be mystified when calls replace
> results in the same subtree and don't replace blocks elsewhere in the
> same Org-mode file.  No other parts of Org-mode's code block support
> work this way.

If the results stop being implicitly named, then that problem (and its
clumsy solution, which doesn't even work correctly yet) is not needed (I
think).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: evaluation context in call statements

[Andreas Leha]

Hi all


Achim Gratz <Stromeko@nexgo.de> writes:

> Eric Schulte writes:
>>>> My vote is for adding #+name support to call lines, and then handling
>>>> their results in the same manner as code block results.
>>
>> Achim Gratz <Stromeko@nexgo.de> writes:
>>> I'm not sure what this would entail other than replacing the call with
>>> its arguments with the name of the call in the results line.  But yes,
>>> that'd be a step forward, although you'd have to be careful when copying
>>> calls.
>>>
>>
>> This could work exactly as named source blocks work.  E.g.,
> [...]
>
> I see.  The problem then really is that #+CALL lines are currently
> "implicitly named" by copying their arguments to the results line.  If
> explicit naming is allowed, this implicit naming should go away or at
> least not be the default, IMHO.
>

[ ... ]

I did not follow this tread, so I just wanted to clarify:  You are talking
about making me to replace

--8<---------------cut here---------------start------------->8---
#+call: number_of_sth(origin="dataset1") :results table
#+call: number_of_sth(origin="dataset2") :results table
--8<---------------cut here---------------end--------------->8---

with

--8<---------------cut here---------------start------------->8---
#+name: call_number_of_sth_with_origin_dataset1
#+call: number_of_sth(origin="dataset1") :results table
#+name: call_number_of_sth_with_origin_dataset2
#+call: number_of_sth(origin="dataset2") :results table
--8<---------------cut here---------------end--------------->8---

?


Such change would make (some of) my orgmode files look rather
complicated.  The 'implicit' naming of call lines does make sense IMO,
as all that may distinguish two call lines really are the arguments.

I understand that there are problems with the current implementation of
call lines.  But I just want to say, that I would vote for not dropping
the implicit naming of call lines -- but for fixing their problems
instead.  An explicit name overriding the default implicit name would
be the preferable solution to me.

Regards,
Andreas

Re: evaluation context in call statements

[Achim Gratz]

Andreas Leha writes:
> I did not follow this tread, so I just wanted to clarify:  You are talking
> about making me to replace
>
> #+call: number_of_sth(origin="dataset1") :results table
> #+call: number_of_sth(origin="dataset2") :results table
>
> with
>
> #+name: call_number_of_sth_with_origin_dataset1
> #+call: number_of_sth(origin="dataset1") :results table
> #+name: call_number_of_sth_with_origin_dataset2
> #+call: number_of_sth(origin="dataset2") :results table

No.  What I'm talking about is that this behaviour is sensible only for
#+CALL lines that have functional semantics (i.e. always produce the
same result as long as the arguments stay the same) and therefore
shouldn't be the (unconditional) default.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: evaluation context in call statements

[Andreas Leha]

Achim Gratz <Stromeko@nexgo.de> writes:

> Andreas Leha writes:
>> I did not follow this tread, so I just wanted to clarify:  You are talking
>> about making me to replace
>>
>> #+call: number_of_sth(origin="dataset1") :results table
>> #+call: number_of_sth(origin="dataset2") :results table
>>
>> with
>>
>> #+name: call_number_of_sth_with_origin_dataset1
>> #+call: number_of_sth(origin="dataset1") :results table
>> #+name: call_number_of_sth_with_origin_dataset2
>> #+call: number_of_sth(origin="dataset2") :results table
>
> No. [...]

Thanks for that reassuring clarification.

- Andreas

Re: evaluation context in call statements

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

Achim Gratz <Stromeko@nexgo.de> writes:

> Eric Schulte writes:
>>>> My vote is for adding #+name support to call lines, and then handling
>>>> their results in the same manner as code block results.
>>
>> Achim Gratz <Stromeko@nexgo.de> writes:
>>> I'm not sure what this would entail other than replacing the call with
>>> its arguments with the name of the call in the results line.  But yes,
>>> that'd be a step forward, although you'd have to be careful when copying
>>> calls.
>>>
>>
>> This could work exactly as named source blocks work.  E.g.,
> [...]
>
> I see.  The problem then really is that #+CALL lines are currently
> "implicitly named" by copying their arguments to the results line.  If
> explicit naming is allowed, this implicit naming should go away or at
> least not be the default, IMHO.
>

Exactly.

I've just pushed up a patch which implements this change.  Call lines
should now work exactly as named code blocks providing clarity,
uniformity and the flexibility to run multiple identical call lines.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: named-call.org --]
[-- Type: text/x-org, Size: 248 bytes --]

#+name: bar
#+BEGIN_SRC emacs-lisp 
:baz
#+END_SRC

#+call: bar()

#+RESULTS:
: :baz

#+call: bar()

#+RESULTS:
: :baz

#+name: foo
#+call: bar()

#+RESULTS: foo
: :baz

#+name: foo2
#+call: bar()

#+RESULTS: foo2
: :baz

#+name: foo
#+call: bar()

[-- Attachment #3: Type: text/plain, Size: 55 bytes --]


Cheers,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: evaluation context in call statements

[Michael Brand]

Hi Eric

On Mon, Jul 1, 2013 at 12:24 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
> I've just pushed up a patch which implements this change.  Call lines
> should now work exactly as named code blocks providing clarity,
> uniformity and the flexibility to run multiple identical call lines.

This is very useful for me sometimes, thank you.

I am now adapting my recent ERT that you disabled in the meantime due
to your changes and therefore have a question. With C-c C-c on this
call line

    #+NAME: src_block_location_shell sect call
    #+CALL: src_block_location_shell()

the result is

    #+RESULTS: src_block_location_shell sect call
    : shell a:1, b:0, c:3, d:0, e:0

as expected. With org-test-with-expanded-babel-code I would expect the
same but get

    #+RESULTS:
    : shell a:1, b:0, c:3, d:0, e:0

Should the behavior of org-test-with-expanded-babel-code not be
aligned?

Michael

Re: evaluation context in call statements

[Eric Schulte]

Michael Brand <michael.ch.brand@gmail.com> writes:

> Hi Eric
>
> On Mon, Jul 1, 2013 at 12:24 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> I've just pushed up a patch which implements this change.  Call lines
>> should now work exactly as named code blocks providing clarity,
>> uniformity and the flexibility to run multiple identical call lines.
>
> This is very useful for me sometimes, thank you.
>
> I am now adapting my recent ERT that you disabled in the meantime due
> to your changes and therefore have a question. With C-c C-c on this
> call line
>
>     #+NAME: src_block_location_shell sect call
>     #+CALL: src_block_location_shell()
>
> the result is
>
>     #+RESULTS: src_block_location_shell sect call
>     : shell a:1, b:0, c:3, d:0, e:0
>
> as expected. With org-test-with-expanded-babel-code I would expect the
> same but get
>
>     #+RESULTS:
>     : shell a:1, b:0, c:3, d:0, e:0
>
> Should the behavior of org-test-with-expanded-babel-code not be
> aligned?
>

Thanks for catching this.

The export function (used by `org-test-with-expanded-babel-code') hadn't
been updated to use call line names.  I've just pushed up a fix.

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: evaluation context in call statements

[Michael Brand]

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

Hi Eric

On Mon, Jul 1, 2013 at 3:11 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
> The export function (used by `org-test-with-expanded-babel-code') hadn't
> been updated to use call line names.  I've just pushed up a fix.

Thanks, attached the adapted patch to have my ERT again testing.

Michael

[-- Attachment #2: 0001-Babel-use-NAME-for-src-block-calls-in-ERT.patch.txt --]
[-- Type: text/plain, Size: 5966 bytes --]

From 22633dd583f2a6270bff4e28eed81f1f0d6a36f5 Mon Sep 17 00:00:00 2001
From: Michael Brand <michael.ch.brand@gmail.com>
Date: Mon, 1 Jul 2013 15:50:15 +0200
Subject: [PATCH] Babel: use NAME for src block calls in ERT

* testing/examples/babel.org(use case of reading entry properties):
Adapt to use the new introduced #+NAME for src block calls.
* testing/lisp/test-ob-exp.el(ob-exp/use-case-of-reading-entry-properties):
Adapt to use the new introduced #+NAME for src block calls.
---
 testing/examples/babel.org  | 42 ++++++++++++++++++++++++++++--------------
 testing/lisp/test-ob-exp.el | 13 ++++++-------
 2 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index de1980e..b1f1702 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -365,7 +365,10 @@ Here is a call line with more than just the results exported.
   :ID:       cc5fbc20-bca5-437a-a7b8-2b4d7a03f820
   :END:
 
-If overriden by caller then use :var from header else use entry property.
+Use case checked and documented with this test: During their
+evaluation the source blocks read values from properties from the
+entry where the call has been made unless the value is overridden with
+the optional argument of the caller.
 
 ** section
    :PROPERTIES:
@@ -375,10 +378,14 @@ If overriden by caller then use :var from header else use entry property.
 
 Note: Just export of a property can be done with a macro: {{{property(a)}}}.
 
-#+CALL: src_block_location_shell(dummy_name="sect call")
-#+CALL: src_block_location_elisp[:session sect call]()
-- sect inline call_src_block_location_shell(dummy_name="sect inline")
-- sect inline call_src_block_location_elisp[:session sect inline]()
+#+NAME: src_block_location_shell sect call
+#+CALL: src_block_location_shell()
+
+#+NAME: src_block_location_elisp sect call
+#+CALL: src_block_location_elisp()
+
+- sect inline call_src_block_location_shell()
+- sect inline call_src_block_location_elisp()
 
 *** subsection
     :PROPERTIES:
@@ -386,20 +393,27 @@ Note: Just export of a property can be done with a macro: {{{property(a)}}}.
     :c:        4
     :END:
 
-#+CALL: src_block_location_shell(dummy_name="sub0 call")
-#+CALL: src_block_location_elisp[:session sub0 call]()
-- sub0 inline call_src_block_location_shell(dummy_name="sub0 inline")
-- sub0 inline call_src_block_location_elisp[:session sub0 inline]()
+#+NAME: src_block_location_shell sub0 call
+#+CALL: src_block_location_shell()
+
+#+NAME: src_block_location_elisp sub0 call
+#+CALL: src_block_location_elisp()
+
+- sub0 inline call_src_block_location_shell()
+- sub0 inline call_src_block_location_elisp()
+
+#+NAME: src_block_location_shell sub1 call
+#+CALL: src_block_location_shell(c=5, e=6)
+
+#+NAME: src_block_location_elisp sub1 call
+#+CALL: src_block_location_elisp(c=5, e=6)
 
-#+CALL: src_block_location_shell(dummy_name="sub1 call", c=5, e=6)
-#+CALL: src_block_location_elisp[:session sub1 call](c=5, e=6)
-- sub1 inline call_src_block_location_shell(dummy_name="sub1 inline", c=5, e=6)
-- sub1 inline call_src_block_location_elisp[:session sub1 inline](c=5, e=6)
+- sub1 inline call_src_block_location_shell(c=5, e=6)
+- sub1 inline call_src_block_location_elisp(c=5, e=6)
 
 **** function definition
 
 #+NAME: src_block_location_shell
-#+HEADER: :var dummy_name="workaround to get different result blocks"
 #+HEADER: :var a=(or (org-entry-get org-babel-current-src-block-location "a" t) "0")
 #+HEADER: :var b=(or (org-entry-get org-babel-current-src-block-location "b" t) "0")
 #+HEADER: :var c=(or (org-entry-get org-babel-current-src-block-location "c" t) "0")
diff --git a/testing/lisp/test-ob-exp.el b/testing/lisp/test-ob-exp.el
index 416e229..d2541d3 100644
--- a/testing/lisp/test-ob-exp.el
+++ b/testing/lisp/test-ob-exp.el
@@ -217,7 +217,6 @@ Here is one at the end of a line. =2=
       (should-not (string-match (regexp-quote "i=\"10\"") result)))))
 
 (ert-deftest ob-exp/use-case-of-reading-entry-properties ()
-  :expected-result :failed ;; TODO: update for new call line result insertion
   (org-test-at-id "cc5fbc20-bca5-437a-a7b8-2b4d7a03f820"
     (org-narrow-to-subtree)
     (let* ((case-fold-search nil)
@@ -227,27 +226,27 @@ Here is one at the end of a line. =2=
 	   (sub1 "a:1, b:2, c:5, d:0, e:6")
 	   (func sub0))
       ;; entry "section"
-      (should (string-match (concat "\"sect call\".*)\n: shell " sect "\n")
+      (should (string-match (concat "_shell sect call\n: shell " sect "\n")
 			    result))
-      (should (string-match (concat "sect call\\](.*)\n: elisp " sect "\n")
+      (should (string-match (concat "_elisp sect call\n: elisp " sect "\n")
 			    result))
       (should (string-match (concat "\n- sect inline =shell " sect "=\n")
 			    result))
       (should (string-match (concat "\n- sect inline =elisp " sect "=\n")
 			    result))
       ;; entry "subsection", call without arguments
-      (should (string-match (concat "\"sub0 call\".*)\n: shell " sub0 "\n")
+      (should (string-match (concat "_shell sub0 call\n: shell " sub0 "\n")
 			    result))
-      (should (string-match (concat "sub0 call\\](.*)\n: elisp " sub0 "\n")
+      (should (string-match (concat "_elisp sub0 call\n: elisp " sub0 "\n")
 			    result))
       (should (string-match (concat "\n- sub0 inline =shell " sub0 "=\n")
 			    result))
       (should (string-match (concat "\n- sub0 inline =elisp " sub0 "=\n")
 			    result))
       ;; entry "subsection", call with arguments
-      (should (string-match (concat "\"sub1 call\".*)\n: shell " sub1 "\n")
+      (should (string-match (concat "_shell sub1 call\n: shell " sub1 "\n")
 			    result))
-      (should (string-match (concat "sub1 call\\](.*)\n: elisp " sub1 "\n")
+      (should (string-match (concat "_elisp sub1 call\n: elisp " sub1 "\n")
 			    result))
       (should (string-match (concat "\n- sub1 inline =shell " sub1 "=\n")
 			    result))
-- 
1.8.3

Re: evaluation context in call statements

[Eric Schulte]

Michael Brand <michael.ch.brand@gmail.com> writes:

> Hi Eric
>
> On Mon, Jul 1, 2013 at 3:11 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> The export function (used by `org-test-with-expanded-babel-code') hadn't
>> been updated to use call line names.  I've just pushed up a fix.
>
> Thanks, attached the adapted patch to have my ERT again testing.
>
> Michael
>

Applied, Thanks

-- 
Eric Schulte
http://cs.unm.edu/~eschulte