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

[Gabor Grothendieck]

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.

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
> >>>
> >>>
>
>