similar to: quote() vs quote(expr=)

On Sat, Oct 15, 2016 at 2:00 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>>> on Wed, 12 Oct 2016 15:21:13 -0700 writes: > > > Thanks, this was what I expected. There is a desire to > > eliminate the usage of pairlist from user code, which > >

Dear R-devel, There is a new feature in R-devel, which explicitly refers to LISP @ operator for splicing. > The backquote function bquote() has a new argument splice to enable splicing a computed list of values into an expression, like ,@ in LISP's backquote. Although the most upvoted SO question asking for exactly LISP's @ functionality in R doesn't seems to be addressed by this

I have two use cases in mind: 1) Code indexing/searching, where the table gets me almost all of the way there, except I ask for all of the text (including the calls) and then parse that, because it's nice to get back an actual code object when you are searching code (in addition to where the code lives). The extra parsing step is just a minor inconvenience. 2) Code analysis, which I'm

Thank you Luke for prompt reply. Is it possible then to request a new function to R C API "message" that would equivalent to R "message" function? Similarly as we now have C "warning" and C "error" functions. Best, Jan On Sun, Sep 15, 2019 at 5:25 PM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > On Sun, 15 Sep 2019, Jan Gorecki wrote:

This seems like a bug to me: code <- 'x <- r"(hello, "world")"' getParseData(parse(text = code)) #> line1 col1 line2 col2 id parent token terminal text #> 7 1 1 1 24 7 0 expr FALSE #> 1 1 1 1 1 1 3 SYMBOL TRUE x #> 3 1 1 1 1 3 7 expr

I don't know, maybe it would make sense to keep the whole expression, that's the text of the tag after all. Also, if we don't keep the whole expression, then it is not a valid string literal any more, because it does not have quoting. I can try to look into a patch. This is for 4.1 I believe, so in some sense it is not urgent? Gabor On Wed, Apr 22, 2020 at 3:31 PM <luke-tierney

Hi! We?ve seen a problem with the compiler in specific cases of matrix updates: > { m <- matrix(1:4, 2) ; z <- 0; for(i in 1) { m[z <- z + 1,z <- z + 1] <- 99; } ; m } [,1] [,2] [1,] 1 3 [2,] 2 99 Here, it modifies element [2,2], which is unexpected. It behaves correct without the loop: > { m <- matrix(1:4, 2) ; z <- 0; m[z <- z + 1,z <- z + 1]

Dear R-devel community, There appears to be an inconsistency in R C API about the exceptions that can be raised from C code. Mapping of R C funs to corresponding R functions is as follows. error -> stop warning -> warning REprintf -> message Rprintf -> cat Rprint/cat is of course not an exception, I listed it just for completeness. The inconsistency I would like to report is

The following example involves a function whose on.exit() expression both generates an error and catches the error. The body of the function also generates an error. When calling the function wrapped in a tryCatch, should that tryCatch's error function be given the error from the body of the function, since the one from the on.exit has already been dealt with? Currently the outer tryCatch

Hi, Is there currently any way to guarantee that on.exit does not fail to execute the recorded expression because of a user interrupt arriving during function exit? Consider: f <- function() { suspendInterrupts({ on.exit(suspendInterrupts(cntr_on.exit <<- cntr_on.exit + 1L)) cntr_f <<- cntr_f + 1L }) TRUE } It is possible to interrupt this function such that cntr_f

I would like to use the 'tryCatch' function but am having a hard time getting my head around it. In 'C' like languages try/catch/finally means try a block of statements and if any throw an error then do the statements in the catch block and then error or not always do the staements in the finally block. In 'R' as best as I can tell the block of staements in the try block is

Luke Thanks ? I revised the code to: ERRORMESSAGE <- try(source(USERSCRIPTFILE, local=T), silent=T) print(ERRORMESSAGE) now returns: $value [1] 0 $visible [1] FALSE Not clear what to make of that. Dennis Dennis Fisher MD P < (The "P Less Than" Company) Phone / Fax: 1-866-PLessThan (1-866-753-7784) www.PLessThan.com > On Feb 22, 2018, at 12:45 PM, luke-tierney at

Hi all, When S4 methods are defined on base function (say, "match"), the function becomes a method with the body "base::match(x,y)". A call to such a function often spends more time doing "::" than in the function itself. I always assumed that "::" was a very low-level thing, but it turns out to be a plain old function defined in base/R/namespace.R. What

Hi all, It's possible to capture the expression associated with a promise (using substitute). Is there any way to capture the environment associated with a promise? Similarly, is there any way to tell if something is a promise without accidentally evaluating it? Thanks! Hadley -- RStudio / Rice University http://had.co.nz/

Hi, Is this expected behavior (R-3.6.0)? dat <- cbind(x = 1:10, y = 10:1) ylab <- substitute(X[t], list(t = 2)) plot(dat, ylab = ylab) # works (correctly displays ylab) boxplot(dat, ylab = ylab) # fails boxplot(dat, ylab = as.expression(ylab)) # works Thanks & cheers, M

Same thing happens with S3 if you redefine print(). I thought that code was actually calculating the function to call rather than the symbol to use, but apparently not. Shouldn't be too hard to fix. luke On Tue, 30 Jun 2015, Hadley Wickham wrote: > On Tue, Jun 30, 2015 at 2:20 PM, Duncan Murdoch > <murdoch.duncan at gmail.com> wrote: >> On 30/06/2015 1:57 PM, Hadley

Dear all As far as I could trace, looking at the function C function numeric_deriv, this unwanted behavior comes from the inner most loop in, at the very end of the function, for(i = 0, start = 0; i < LENGTH(theta); i++) { for(j = 0; j < LENGTH(VECTOR_ELT(pars, i)); j++, start += LENGTH(ans)) { SEXP ans_del; double origPar, xx, delta; origPar = REAL(VECTOR_ELT(pars, i))[j];

Shouldn't the following 4 ways to alter an object in a locked environment either all work or all fail? (All working would be nice, I think.) E <- new.env() assign("var", c(1,2,3,4), envir=E) lockEnvironment(E, bindings=FALSE) E$var[1] <- 101 ; E$var #[1] 101 2 3 local(var[2] <- 102, envir=E) #Error in eval(expr, envir, enclos) : # cannot add

Sorry for reposting, i keep forgetting this should be plain text. Will not make this mistake again Hello, The following code moo <- function(a=1){ x=1; x=x+y} funs <- new.env() enter <- function(type, v, e, w){ assign(v, TRUE, funs) } library(codetools) collectUsage(moo, enterGlobal = enter) adds + to the environment funs i.e. funs: "=" "{" "+"

I noticed some problems that cropped in the latest versions of R-devel (2016-11-08 r71639 in my case) for one of my packages. I _think_ I have narrowed it down to the changes to what gets byte-compiled by default. The following example run illustrates the problem I'm having: compiler::enableJIT(0) fun <- function(x) local(as.list(parent.frame(2))) fun(1) ## $x ## [1] 1 ##