similar to: The stages of standard function evaluation

Would you consider the following patch to eval.c to allow compatibility with RCC? (It's in the applyClosure function.) @@ -432,6 +432,14 @@ SEXP f, a, tmp; RCNTXT cntxt; +#ifdef RCC + SEXP comp; + PROTECT(comp = getAttrib(op, install("RCC_CompiledSymbol"))); + if (comp != R_NilValue) /* compiled version exists */ + op = comp; + UNPROTECT(1); +#endif

On Jan 28, 2015, at 6:37 PM, Michael Lawrence <lawrence.michael at gene.com> wrote: > At this point I would just due: > > formals(body(method)[[2L]]) > > At some point we need to figure out what to do with this .local() confusion. Agreed, definitely. The current hack is to avoid re-matching arguments on method dispatch, so a fix would need to be fairly deep in the

Hello R-help, I've noticed that my 'parallel' jobs take too much memory to store and transfer to the cluster workers. I've managed to trace it to the following: # `payload` is being written to the cluster worker. # The function FUN had been created as a closure inside my package: payload$data$args$FUN # function (l, ...) # withCallingHandlers(fun(l$x, ...), error =

I'm attempting to reflect the information for use with corresponding fields in GUI (in a different package), to provide default values, argname as key for UI label lookups, etc. So I want something much more like the formals of the implementation: { "object", "method": c("median", "vs", "tukey"),

On Mon, 26 Mar 2007, Christopher Lamb wrote: >> For representing scoping information, a relatively non-invasive >> approach is to introduce a special "copy" operation, which in LLVM >> might look like >> %a = copy %b >> This operation has to be somewhat special in that can't be folded away >> in most cases, but it can otherwise be pretty

Michael Lawrence (as last in long series of posters)... > Yes, it would bind the language object to the environment, like an > R-level promise (but "promise" of course refers specifically to just > _lazy_ evaluation). > > For the uqs() thing, expanding calls like that is somewhat orthogonal > to NSE. It would be nice in general to be able to write something like >

I'm confused by this: > identical(function() {}, function() {}) [1] FALSE Yet, after loading the Matrix package (which redefines det), the following is checked (in library.checkConflicts): > identical(get("det", baseenv()), get("det", asNamespace("Matrix")), ignore.environment=T) [1] TRUE I've looked at the code in identical.c and for closures it

After many hours of debugging code, I came to the conclusion that I have a fundamental misunderstanding regarding eval, and hope that someone here can explain to me, why the following code acts as it does: foo <- function(expr) { eval(substitute(expr), envir=list(a=5), enclos=parent.frame()) } bar <- function(er) { foo(er) } > foo(a) [1] 5 > bar(a) Error in eval(expr,

Hi, A question (& possible suggestion) about function calls. Is there an R idiom to eliminate the redundancy in the following common situation? foo <- function(x, control=ComplicatedDefault) { etc. } plotfoo <- function(x, foocontrol=ComplicatedDefault, ...) { y <- foo(x, control=foocontrol) lines(x,y,...) } The idea is that there are MANY

6 ?????? 2023 ?. 22:54:24 GMT+03:00, mikkmart via R-devel <r-devel at r-project.org> ?????: >The pattern of functions accepting other functions as inputs and >passing additional ... arguments to them is prevalent throughout >the R ecosystem. Currently, however, all such functions must one >way or another tackle the problem of inadvertently passing arguments >meant to go to

I've just spent today trying to fix a Heisenbug... this function returns a linear interpolator function: interpOne <- function(xl,yl){ f = function(data){ t = (data-min(xl))/(max(xl)-min(xl)) return(min(yl)+t*(max(yl)-min(yl))) } return(f) } > k=interpOne(c(0,1),c(4,5)) > k(0.5) [1] 4.5 and this function uses the above to return a function that returns a piece-wise

Hi, The R input/output after the following paragraph is from a session with version.string R version 2.4.0 Patched (2006-11-23 r39958). The last element, x$c, of x has no value and after the assignment of x to the formals of f, x$c does not become a formal argument of f. The second assignment does the job. It seems that x$c actually becomes the body of f after the first assignment. There is no

I wish it didn't have to depend on the name '.local'. Back when I wrote a lot of S4 methods I avoided the auto-generated .local and named the local function something that made sense so that is was easier for a user to track down the source of an error. E.g., define the generic QQQ with numeric and integer methods: setGeneric("QQQ", function(x, ...)NULL)

Would we really need the special class or would simply checking the formals of the method against those of the generic be simple and fast enough? On Thu, Jan 29, 2015 at 9:41 AM, John Chambers <jmc at r-project.org> wrote: > I wouldn't want to add more to the current approach; if someone would like > to devote some time, the much preferable idea IMO would be to replace the >

Duncan, Thank you for the clarification on how delayedAssign works. Should R-level interfaces to promise objects ever become available, I expect they would at time come in handy. On the subject of substitute and delayedAssign, I do have a follow-up question for the list. I'm trying to convert a named list of expression objects into an environment of promise objects. After conversion, each

This has been asked before, but I just cannot figure out why lapply should behave this way given that R uses lazy evalution. Even after reading (or at least trying to read) parts of the R language definition. > f <- function(x) {function() {x}} > a <- list(f(1), f(2), f(3)) > a[[1]]() # as expected [1] 1 > a[[2]]() # as expected [1] 2 > a[[3]]() # as expected [1] 3 > b

Hello R experts, I plan to develop a tool for dynamic analysis of R programs. I would like to trace function calls at runtime, capturing argument and return values. Following a suggestion made some time ago on this list, my high-level implementation strategy is to rewrite the AST, augmenting call expressions with pre-call and post-call shims to capture the arguments and return value,

Hi, Thanks for the note. How would explain the following snippet taken from `formals` doc page (the code comment is also from that doc) ? ## formals returns NULL for primitive functions. Use it in combination with ## args for this case. is.primitive(`+`) formals(`+`) formals(args(`+`)) Le sam. 6 oct. 2018 ? 13:42, Rui Barradas <ruipbarradas at sapo.pt> a ?crit :

Full_Name: Jörg Polzehl Version: 1.8.0 OS: Windows XP Submission from: (NULL) (62.141.176.1) I encountered a problem when playing with the mle library and specifying negative starting values for the parameters. The reason seems to be an incorrect behaviour of function formals: glike<-function(a=1,b=1,c=1) a > formals(glike) $a [1] 1 $b [1] 1 $c [1] 1 > unlist(formals(glike)) a b c

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Mon, 27 Feb 2017 10:42:19 +0100 writes: >>>>> Rob J Hyndman <Rob.Hyndman at monash.edu> >>>>> on Wed, 15 Feb 2017 21:48:56 +1100 writes: >> The generic stats::median method is defined as median <- >> function (x, na.rm = FALSE)