[Rd] withAutoprint({ .... }) ?

[Kirill Müller]

On 02.09.2016 14:38, Duncan Murdoch wrote:
> On 02/09/2016 7:56 AM, Martin Maechler wrote:
>> On R-help, with subject
>>    '[R] source() does not include added code'
>>
>>>>>>> Joshua Ulrich <josh.m.ulrich at gmail.com>
>>>>>>>     on Wed, 31 Aug 2016 10:35:01 -0500 writes:
>>
>>     > I have quantstrat installed and it works fine for me. If you're
>>     > asking why the output of t(tradeStats('macross')) isn't being 
>> printed,
>>     > that's because of what's described in the first paragraph in the
>>     > *Details* section of help("source"):
>>
>>     > Note that running code via ‘source’ differs in a few respects from
>>     > entering it at the R command line.  Since expressions are not
>>     > executed at the top level, auto-printing is not done. So you will
>>     > need to include explicit ‘print’ calls for things you want to be
>>     > printed (and remember that this includes plotting by ‘lattice’,
>>     > FAQ Q7.22).
>>
>>
>>
>>     > So you need:
>>
>>     > print(t(tradeStats('macross')))
>>
>>     > if you want the output printed to the console.
>>
>> indeed, and "of course"" ;-)
>>
>> As my subject indicates, this is another case, where it would be
>> very convenient to have a function
>>
>>    withAutoprint()
>>
>> so the OP could have (hopefully) have used
>>    withAutoprint(source(..))
>> though that would have been equivalent to the already nicely existing
>>
>>    source(.., print.eval = TRUE)
>>
>> which works via the  withVisible(.) utility that returns for each
>> 'expression' if it would auto print or not, and then does print (or
>> not) accordingly.
>>
>> My own use cases for such a withAutoprint({...})
>> are demos and examples, sometimes even package tests which I want to 
>> print:
>>
>> Assume I have a nice demo / example on a help page/ ...
>>
>> foo(..)
>> (z <- bar(..))
>> summary(z)
>> ....
>>
>> where I carefully do print parts (and don't others),
>> and suddenly I find I want to run that part of the demo /
>> example / test only in some circumstances, e.g., only when
>> interactive, but not in BATCH, or only if it is me, the package 
>> maintainer,
>>
>> if( identical(Sys.getenv("USER"), "maechler") ) {
>>   foo(..)
>>   (z <- bar(..))
>>   summary(z)
>>   ....
>> }
>>
>> Now all the auto-printing is gone, and
>>
>> 1) I have to find out which of these function calls do autoprint and 
>> wrap
>>    a print(..) around these, and
>>
>> 2) the result is quite ugly (for an example on a help page etc.)
>>
>> What I would like in a future R, is to be able to simply wrap the "{
>> .. } above with an 'withAutoprint(.) :
>>
>> if( identical(Sys.getenv("USER"), "maechler") ) withAutoprint({
>>   foo(..)
>>   (z <- bar(..))
>>   summary(z)
>>   ....
>> })
>>
>> Conceptually such a function could be written similar to source() 
>> with an R
>> level for loop, treating each expression separately, calling eval(.) 
>> etc.
>> That may cost too much performnace, ... still to have it would be 
>> better than
>> not having the possibility.
>>
>> ----
>>
>> If you read so far, you'd probably agree that such a function
>> could be a nice asset in R,
>> notably if it was possible to do this on the fast C level of R's main
>> REPL.
>>
>> Have any of you looked into how this could be provided in R ?
>> If you know the source a little, you will remember that there's
>> the global variable  R_Visible  which is crucial here.
>> The problem with that is that it *is* global, and only available
>> as that; that the auto-printing "concept" is so linked to "toplevel 
>> context"
>> and that is not easy, and AFAIK not so much centralized in one place 
>> in the
>> source. Consequently, all kind of (very) low level functions 
>> manipulate R_Visible
>> temporarily.... and so a C level implementation of withAutoprint() may
>> need considerable more changes than just setting R_Visible to TRUE in 
>> one
>> place.
>>
>> Have any efforts / experiments already happened towards providing such
>> functionality ?
>
> I don't think the performance cost would matter.  If you're printing 
> something, you're already slow.  So doing this at the R level would 
> make most sense to me --- that's how Sweave and source and knitr do 
> it, so it can't be that bad.
>
> Duncan Murdoch
>
A C-level implementation would bring the benefit of a lean traceback() 
in case of an error. I suspect eval() could be enhanced to auto-print.

By the same token it would be extremely helpful to have a C-level 
implementation of local() which wouldn't litter the stack trace.


-Kirill