emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Andreas Leha <andreas.leha@med.uni-goettingen.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: problems with export and :cache
Date: Sun, 01 Nov 2015 23:56:49 +0100	[thread overview]
Message-ID: <87io5ll45q.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <877fm5xzpm.fsf@gmail.com> (Aaron Ecay's message of "Thu, 29 Oct 2015 19:05:25 +0000")

Hello,

Aaron Ecay <aaronecay@gmail.com> writes:

> If this means “can it ever work?” then I think the answer is “yes it
> can”.  But I think the current implementation is broken and likely to
> remain so for the foreseeable future.  The issues are:
>
> 1. :cache only works for code which is a pure function of its header args
> 2. When combined with :session, the environment that the code is evaluated
>    in is not created anew each time it is run.  This makes it much easier
>    to leak references to (e.g.) variables defined in other blocks
> 3. The proper notion of purity is not easily defined when the code does
>    things like modifying the emacs environment, touching the filesystem,
>    or accessing the language’s RNG.
> 4. We (org devs) don’t actually understand how the semantics of cache
>    interacts with other babel features.  See:
>    <http://mid.gmane.org/86fvqqc8jb.fsf@somewhere.org>.
>
> 1-3 are likely to be extremely confusing for users, especially less
> technically sophisticated ones (what’s a “pure function” anyway)?  The
> inability to give a clear introductory explanation of the feature in
> combination with 4 indicating we don’t actually understand it ourselves
> makes me feel like we should not be advertising, let alone recommending,
> it.
>
> The only other literate programming environment that I know of that
> implements such a feature is knitr (for R).  They address these issues
> by providing (optional) free-variable analysis to construct a dependency
> graph between code blocks.  There is also some handling of RNG seed
> values.  The documentation <http://yihui.name/knitr/demo/cache/> is much
> more comprehensive, including a prominent statement about the dangers of
> side effect-ful code and a nuanced discussion of several issues,
> including the RNG.

Thank you for the explanations.

Assuming the user knows what s?he is doing (so I'm not bothered by
issues 2 and 3), :cache is still a somewhat useful feature. I don't mind
advertising it. Though, I agree we could include big fat warnings about
it in the manual.

Also, :cache might be a bit misleading as it implies more than what this
feature offer, i.e., a dumb "don't update results if contents didn't
change". I cannot think of a better name, tho.


Regards,

-- 
Nicolas Goaziou

  parent reply	other threads:[~2015-11-01 22:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28 21:37 problems with export and :cache Andreas Leha
2015-10-28 21:45 ` Andreas Leha
2015-10-29 13:34   ` Aaron Ecay
2015-10-29 14:22     ` Nicolas Goaziou
2015-10-29 15:14       ` Aaron Ecay
2015-10-29 16:42         ` Nicolas Goaziou
2015-10-29 17:05           ` Aaron Ecay
2015-10-29 17:16             ` Nicolas Goaziou
2015-10-29 19:11         ` Aaron Ecay
2015-10-30 23:40           ` Andreas Leha
2015-11-07 16:37         ` Achim Gratz
2015-11-07 20:33           ` Aaron Ecay
2015-11-07 22:43             ` Achim Gratz
2015-10-29 14:58     ` Andreas Leha
2015-10-29 15:17       ` Aaron Ecay
2015-10-29 16:51       ` Nicolas Goaziou
2015-10-29 19:05         ` Aaron Ecay
2015-10-29 20:32           ` Thomas S. Dye
2015-10-29 23:01             ` Andreas Leha
2015-11-01 22:56           ` Nicolas Goaziou [this message]
2015-11-04 12:01             ` Aaron Ecay
2015-11-04 22:41               ` Nicolas Goaziou
2015-11-05 14:51                 ` Aaron Ecay
2015-11-05 14:55                   ` Nicolas Goaziou

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=87io5ll45q.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=andreas.leha@med.uni-goettingen.de \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).