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

[Duncan Murdoch]

On 10/26/2006 7:12 AM, Gabor Grothendieck wrote:
> Perhaps there could be a set of functions that are made available
> without the promise of future compatibility but with the promise
> that they will change less frequently than if they were not documented
> and if they are changed the changes will be highlighted
> to make it easier for the users of the API to know about such
> changes.  That might overcome resistance stemming from the
> fear of prematurely setting design decisions in stone.

Actually, I think that's about as much of a guarantee as things that are 
set in stone get.  R is built of soft stone :-).

Duncan Murdoch

> 
> On 10/26/06, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
>> On 10/26/2006 6:28 AM, Philippe Grosjean wrote:
>>>> On 10/26/06, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
>>> [...]
>>>>> Actually, there is a way, but it's undocumented (i.e., use at your own
>>>>> risk).  It's the eval.with.vis function.  This is an internal function
>>> Yes... and there are three problems here:
>>> 1) To spot the undocumented function one is looking for,
>>> 2) To figure out how to use it,
>>> 3) To rewrite your code regularly if you maintain packages that use
>>> several of such undocumented functions. This is the case of many R GUI
>>> projects... and one reason why staying up-to-date with the new versions
>>> of R (every 6 months) is a nightmare for these GUIs!
>> Those are definitely real problems.
>>
>> 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.
>>
>> 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
>>>>>
>>>>>
>>