From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: problems with export and :cache Date: Thu, 29 Oct 2015 19:05:25 +0000 Message-ID: <877fm5xzpm.fsf@gmail.com> References: <87vb9pyf0l.fsf@gmail.com> <87oafhoby4.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44008) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrsVy-0007b0-HC for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 15:05:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrsVu-0008RT-DH for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 15:05:34 -0400 Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]:35554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrsVu-0008RE-7z for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 15:05:30 -0400 Received: by wmll128 with SMTP id l128so30728984wml.0 for ; Thu, 29 Oct 2015 12:05:29 -0700 (PDT) In-Reply-To: <87oafhoby4.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou , Andreas Leha Cc: emacs-orgmode@gnu.org Hi Nicolas, 2015ko urriak 29an, Nicolas Goaziou-ek idatzi zuen: >=20 > Andreas Leha writes: >=20 >> Generally, I think that caching is a sensitive area. And if we think >> that it is unpredictable and advise people to stay off of it, we are >> better off removing it than offering it in this state. At least until >> it behaves (more) predictable. >=20 > Is it necessarily broken? If this means =E2=80=9Ccan it ever work?=E2=80=9D then I think the answer i= s =E2=80=9Cyes it can=E2=80=9D. 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=E2=80=99s RNG. 4. We (org devs) don=E2=80=99t actually understand how the semantics of cac= he interacts with other babel features. See: . 1-3 are likely to be extremely confusing for users, especially less technically sophisticated ones (what=E2=80=99s a =E2=80=9Cpure function=E2= =80=9D anyway)? The inability to give a clear introductory explanation of the feature in combination with 4 indicating we don=E2=80=99t actually understand it ourse= lves 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 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. Aaron PS I=E2=80=99ve looked through my old notes on the interaction of cache with babel export. I can=E2=80=99t reproduce any of my old test cases, so maybe= that bug has been fixed as a side effect of some other change. =20 --=20 Aaron Ecay