[Rd] length of `...`

Suharto Anggono Suharto Anggono @uh@rto_@nggono @ending from y@hoo@com
Sun May 6 13:44:04 CEST 2018


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



More information about the R-devel mailing list