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 <[EMAIL PROTECTED]> wrote:
>> On 10/26/2006 6:28 AM, Philippe Grosjean wrote:
>>>> On 10/26/06, Duncan Murdoch <[EMAIL PROTECTED]> 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
>>>>>
>>>>>
>>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
