[Rd] how to determine if a function's result is invisible

[Philippe Grosjean]

Duncan Murdoch wrote:
[...]
> At the last useR meeting, Thomas Baier made an excellent suggestion: 
> someone should put together an API specifically for R GUIs.  I think 
> eval.with.vis would have to be part of such an API; there are dozens of 
> other currently undocumented or unavailable functions as well.

Ah, ha! I am very happy to discover that Thomas Baier had this excellent 
idea at the last useR meeting. It is almost four years that I claims for 
a R GUI API. If you look  at the manual that comes with the SciViews 
bundle (available on CRAN), you will notice that there is a manual 
called 'SciViews-R, A GUI API and a suite of application for R' (see 
http://www.sciviews.org/SciViews-R/Manual.pdf) with about 50 pages that 
discuss several aspects related to R GUI APIs.

There are also threads in the R Wiki that discusses a similar topic 
(although more related to graphical widgets): 
http://wiki.r-project.org/rwiki/doku.php?id=developers:iwidgets&s=api, 
http://wiki.r-project.org/rwiki/doku.php?id=developers:gwidgets_api.
This is mainly the work of John Versani, after a discussion between Him, 
Simon Urbanek (iWidgets), Michael Lawrence (RGtk2), and myself (SciViews).

That said, I did several attempt to put all people at R-SIG-GUI around a 
table to define a common R GUI API,... and I got no significant echo. 
So, I personally give up with this topic and look at what others, 
perhaps stronger than me in R programming or in communication with other 
developers, will do.

But, please, do not give credit for "first idea" to someone else on such 
a topic... It is long enough that I fight for better R GUIs (for 
instance, http://www.r-project.org/GUI), that this looks offending to me!

Best,

Philippe Grosjean

> This is a difficult project, because it would have to get agreement on 
> what should be part of the API, and that will constrain future changes: 
>  so there would be a lot of resistance to making it too constraining. It 
> will need to be flexible, so that R isn't required to supply services 
> that don't make sense in all contexts.
> 
> Duncan Murdoch
> 
>> For instance, I use eval.with.vis() in the latest version of svSockets 
>> package in the SciViews bundle, but I am afraid to release it on CRAN 
>> because I know of the nightware I will face if this function 
>> (silently) changes its behavior in subsequent versions of R.
>>
>> I guess there is no solution to this problem, since there is certainly 
>> a good reason for keeping portions of R code undocumented (and thus 
>> flagged as :" use-it-at-your-own-risk!"), but it does not eases our life!
>>
>> Best,
>>
>> Philippe Grosjean
>>
>>>> that is used within source() and capture.output(); you'll have to guess
>>>> from the usage there what the args are.   But here's an F that does
>>>> something close to what you want:
>>>>
>>>>  > fix(F)
>>>>  > f <- function() 1
>>>>  > g <- function() invisible(1)
>>>>  >
>>>>  > F <- function (expr)
>>>> + {
>>>> +     expr <- substitute(expr)
>>>> +     pf <- parent.frame()
>>>> +     tmp <- .Internal(eval.with.vis(expr, pf,
>>>> +         baseenv()))
>>>> +     tmp
>>>> + }
>>>>  > F(f())
>>>> $value
>>>> [1] 1
>>>>
>>>> $visible
>>>> [1] TRUE
>>>>
>>>>  > F(g())
>>>> $value
>>>> [1] 1
>>>>
>>>> $visible
>>>> [1] FALSE
>>>>
>>>>
> 
> 
>