[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] problems with export and :cache

From: Nicolas Goaziou
Subject: Re: [O] problems with export and :cache
Date: Sun, 01 Nov 2015 23:56:49 +0100


Aaron Ecay <address@hidden> 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/address@hidden>.
> 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.


Nicolas Goaziou

reply via email to

[Prev in Thread] Current Thread [Next in Thread]