similar to: length of `...`

Hi, It would be great if one of the experts could comment on the difference between Hadley's dotlength and ...length? The fact that someone bothered to implement a new primitive for that when there seems to be a very simple and straightforward R-only solution suggests that there might be some gotchas/pitfalls with the R-only solution. Thanks, H. On 05/03/2018 08:34 AM, Hadley Wickham

On 03/05/2018 11:01 AM, William Dunlap via R-devel wrote: > In R-3.5.0 you can use ...length(): > > f <- function(..., n) ...length() > > f(stop("one"), stop("two"), stop("three"), n=7) > [1] 3 > > Prior to that substitute() is the way to go > > g <- function(..., n) length(substitute(...())) > >

Dear R Core Team, I learnt approx. two years ago in this mailing list that one can use the following "trick" to get a (dotted pair)list of the ellipsis arguments inside a function: `substitute(...())` Now my problem is that I can not find any occurrence of this call within the R source - the most frequent solution there is `substitute(list(...))[-1L] ` I would like to know if: 1)

And the related: > f = function() stop(return("lol")) > f() [1] "lol" I have a feeling all of this is just return() performing correctly though. If there are already R CMD CHECK checks for this kind of thing (I wasnt sure but I'm hearing from others there may be/are) that may be (and/or may need to be) sufficient. ~G On Fri, Nov 20, 2020 at 3:27 PM D?nes T?th

Without having dug into the details, it could be that one could update the parser by making a 'return' a keyword and require it to be followed by a parenthesis that optionally contains an expression followed by end of statement (newline or semicolon). Such a "promotion" of the 'return' statement seems backward compatible and would end up throwing syntax errors on:

In R-3.5.0 you can use ...length(): > f <- function(..., n) ...length() > f(stop("one"), stop("two"), stop("three"), n=7) [1] 3 Prior to that substitute() is the way to go > g <- function(..., n) length(substitute(...())) > g(stop("one"), stop("two"), stop("three"), n=7) [1] 3 R-3.5.0 also has the ...elt(n)

On 20/11/2020 7:01 p.m., Ben Bolker wrote: > I may be unusual but I don't find these examples surprising at all/ > I don't think I would make these mistakes (maybe it's easier to make > that mistake if you're used to a language where 'return' is a keyword > rather than a function? > > My two cents would be that it would make more sense to (1) write

On 08/30/2018 01:56 PM, Joris Meys wrote: > I have to agree with Emil here. && and || are short circuited like in C and > C++. That means that > > TRUE || c(TRUE, FALSE) > FALSE && c(TRUE, FALSE) > > cannot give an error because the second part is never evaluated. Throwing a > warning or error for > > c(TRUE, FALSE) || TRUE > > would mean

The one difference I see, is the necessity to pass the dots to the function dotlength : dotlength <- function(...) nargs() myfun <- function(..., someArg = 1){ n1 <- ...length() n2 <- dotlength() n3 <- dotlength(...) return(c(n1, n2, n3)) } myfun(stop("A"), stop("B"), someArg = stop("c")) I don't really see immediately how one can

Benjamin, You happened to send a link which points to the OP's own package :) I think Jiefei would like to know how one can "officially" determine if an arbitrary ALTERP object belongs to a class that he owns. Regards, Denes On 10/19/20 10:22 AM, Benjamin Christoffersen wrote: > It seems as if you can you use the ALTREP macro as done in this > package:

>>>>> Joris Meys >>>>> on Thu, 30 Aug 2018 14:48:01 +0200 writes: > On Thu, Aug 30, 2018 at 2:09 PM D?nes T?th > <toth.denes at kogentum.hu> wrote: >> Note that `||` and `&&` have never been symmetric: >> >> TRUE || stop() # returns TRUE stop() || TRUE # returns an >> error >>

As of 3.5.0 the ...length() function does exactly what you are asking for. Before that, I don't know of an easy way to get the length without evaluation via R code. There may be one I'm not thinking of though, I haven't needed to do this myself. Hope that helps. ~G On Thu, May 3, 2018 at 7:52 AM, Mark van der Loo <mark.vanderloo at gmail.com> wrote: > This question is

AFAIK there is no hashing utility in base R which can create hash digests of arbitrary R objects. However, as also described by Henrik Bengtsson in [1], we have tools::md5sum() which calculates MD5 hashes of files. Calculating hashes of in-memory objects is a very common task in several areas, as demonstrated by the popularity of the 'digest' package (~850.000 downloads/month). Upon

Hi Tim, I have also asked a similar question a couple of months ago, and someone else did the same recently, maybe on r-devel. We received no "official" response, but Deepayan Sarkar (R Core Team member) claimed that: " There is no documented reason for this to work (AFAIK), so again, I would guess this is a side-effect of the implementation, and not a API feature you should

Hmm, looks like that thread has more noise than signal... AFAICT, data.table currently fails selftests i 3.5.0 on all platforms on the CRAN builders, so RTools issues are only incidental and it would be better to fix data.table in the sources. From the looks of it, I wouldn't be surprised if the root cause is the changes to POSIXlt methods in 3.5.0, but I haven't actually been digging

This is very nice to learn about, Denis, but it seems only fair to point out that the result of rbindlist is not a data frame. You can convert it to a data frame easily, but the copy and indexing semantics of data tables are quite different than data tables, which could be a real headache for someone not prepared for those differences. (To learn more, read the data tables vignette.) Tibbles (as

You might find this discussion useful, too: https://github.com/Rdatatable/data.table/issues/2797 On 04/26/2018 11:01 PM, Henrik Bengtsson wrote: > If you're installing packages to the default location in your home > account and you didn't remove those library folders, you still have > you R 3.4 package installs there, e.g. > >> dir(dirname(.libPaths()[1]), full.names =

I probably need to be more specific. What confuses me is not the use of substitute, but the parenthesis after the dots. It clearly works and I can make guesses as to why but it is definitely not obvious. The following function gives the same final result but I can understand what is happening. dots <- function (...) { exprs <- substitute(list(...)) as.list(exprs[-1]) } In the

Thank Denes for the clarification, glad to see my package got one citation from my own question:) Also, thank Benjamin for sending many useful documents. Actually, the question is related to the SharedObject package that Benjamin has pointed to. I wanna avoid sharing an object that has already been shared, so I need to check whether an object is an ALTREP that is defined in my package. Since the

Dear R-Core Team, I found an unexpected behaviour in utils::removeSource (also present in r-devel as of today). --- # create a function which accepts NULL argument foo <- function(x, y) { if (is.null(y)) y <- "default foo" attr(x, "foo") <- y x } # create a function which utilizes 'foo' testSrc <- function() { x <- 1:3 x <- foo(x,