Does anyone notice r-devel thread "stopifnot() does not stop at first non-TRUE argument" starting with https://stat.ethz.ch/pipermail/r-devel/2017-May/074179.html ?
I have mentioned (function(...)nargs())(...) in https://stat.ethz.ch/pipermail/r-devel/2017-May/074294.html . Something like ..elt(n) is switch(n, ...) . I have mentioned it in https://stat.ethz.ch/pipermail/r-devel/2017-May/074270.html . See also response in https://stat.ethz.ch/pipermail/r-devel/2017-May/074282.html . By the way, because 'stopifnot' in R 3.5.0 contains argument other than '...', it might be better to use match.call(expand.dots=FALSE)$... instead of match.call()[-1L] . ------------------------------------------- >>>>> Joris Meys <jorismeys at gmail.com> >>>>> on Fri, 4 May 2018 15:37:27 +0200 writes: > 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 replace the C definition with > Hadley's solution without changing how the function has to be used. Yes, of course: nargs() can only be applied to the function inside which it is used, and hence n2 <- dotlength() must therefore be 0. Thank you, Joris > Personally, I have no preference over the use, but changing it now would > break code dependent upon ...length() imho. Unless I'm overlooking > something of course. Yes. OTOH, as it's been very new, one could consider deprecating it, and advertize say, .length(...) instead of ...length() [yes, in spite of the fact that the pure-R solution is slower than a primitive; both are fast enough for all purposes] But such a deprecation cycle typically entails time more writing etc, not something I've time for just these days. Martin > On Fri, May 4, 2018 at 3:02 PM, Martin Maechler <maechler at stat.math.ethz.ch> > wrote: >> >>>>> Hervé Pagès <hpages at fredhutch.org> >> >>>>> on Thu, 3 May 2018 08:55:20 -0700 writes: >> >> > 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. >> >> Namely >> >> > dotlength <- function(...) nargs() >> >> > (This is subtly different from calling nargs() directly as it will >> > only count the elements in ...) >> >> > Hadley >> >> >> Well, I was the "someone". In the past I had seen (and used myself) >> >> length(list(...)) >> >> and of course that was not usable. >> I knew of some substitute() / match.call() tricks [but I think >> did not know Bill's cute substitute(...()) !] at the time, but >> found them too esoteric. >> >> Aditionally and importantly, ...length() and ..elt(n) were >> developed "synchronously", and the R-substitutes for ..elt() >> definitely are less trivial (I did not find one at the time), as >> Duncan's example to Bill's proposal has shown, so I had looked >> at .Primitive() solutions of both. >> >> In hindsight I should have asked here for advice, but may at >> the time I had been a bit frustrated by the results of some of >> my RFCs ((nothing specific in mind !)) >> >> But __if__ there's really no example where current (3.5.0 and newer) >> >> ...length() >> >> differs from Hadley's dotlength() >> I'd vert happy to replace ...length 's C based definition by >> Hadley's beautiful minimal solution. >> >> Martin ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
