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
