emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Leo Alekseyev <dnquark@gmail.com>
To: Emacs orgmode <emacs-orgmode@gnu.org>
Subject: Re: org-babel order of evaluation
Date: Thu, 12 Jan 2012 16:35:31 -0600	[thread overview]
Message-ID: <CADzxs1mgxV=M_k4wUBiTe9hoNO65ii8Op9BVQ8wKVa_cx0wQ1w@mail.gmail.com> (raw)
In-Reply-To: <87y5td7z2t.fsf@gmx.com>

>> Therefore, when executing an entire buffer, there is no way to have
>> the execution of a call block dependent on the prior execution of a
>> source block.
>>
>
> It would be better to make the dependency explicit by passing the
> results of the call line as a (potentially unused) variable to the code
> block.  For example;
[snip]
>
> There is (at least currently) no guarantee that evaluation order will be
> buffer order.

I've been extremely confused by this in the past; this should be
prominently documented.  In the long run, I would like to see this
behavior changed.  One would intuitively expect all the source code in
the file to be evaluated in order.  This is how it works in pretty
much any other interpreter, why should org-babel be different?

(I'm a big fan of the principle of least surprise, and this behavior
violates it with vengeance :)  )

This is particularly nasty because many users start by treating an
org-babel file as a fancier version of the original source code with
nice annotations and outline levels; typically in a single language.
Thus, operationally, there isn't a distinction between tangling the
blocks into a single source file and feeding that to the interpreter
and running execute on the whole buffer.  But then, of course, one
might start using named blocks, variables, and #+call directives.  It
achieves the same effect as writing wrapper functions (or issuing
statements like source("somefile")) in the original language.  So,
when it results in a completely different execution order, it's a huge
surprise.

Even if this can be fixed by putting dummy dependencies in by hand,
this fix  seems inelegant and hacky.

Is there some deep rationale for the current behavior that I'm not
seeing?  Are there big obstacles to enforcing ligeral execution order?

--Leo

next prev parent reply	other threads:[~2012-01-12 22:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-12  0:25 org-babel order of evaluation Rick Frankel
2012-01-12 14:43 ` Eric Schulte
2012-01-12 22:35   ` Leo Alekseyev [this message]
2012-01-12 22:51     ` Rick Frankel
2012-01-13  1:07       ` Eric Schulte
2012-01-13  1:52         ` Rick Frankel
2012-01-20 17:58           ` Leo Alekseyev
2012-01-23 17:56             ` Eric Schulte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADzxs1mgxV=M_k4wUBiTe9hoNO65ii8Op9BVQ8wKVa_cx0wQ1w@mail.gmail.com' \
    --to=dnquark@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).