[Rd] :: and ::: as .Primitives?

[Michael Lawrence]

On Fri, Jan 23, 2015 at 10:11 AM, Hervé Pagès <hpages at fredhutch.org> wrote:
> Hi,
>
> On 01/23/2015 07:01 AM, luke-tierney at uiowa.edu wrote:
>>
>> On Thu, 22 Jan 2015, Michael Lawrence wrote:
>>
>>> On Thu, Jan 22, 2015 at 11:44 AM,  <luke-tierney at uiowa.edu> wrote:
>>>>
>>>>
>>>> For default methods there ought to be a way to create those so the
>>>> default method is computed at creation or load time and stored in an
>>>> environment.
>>>
>>>
>>> We had considered that, but we thought the definition of the function
>>> would be easier to interpret if it explicitly specified the namespace,
>>> instead of using tricks with environments. The same applies for
>>> memoizing the lookup in front of a loop.
>>
>>
>> interpret in what sense (human reader or R interpreter)? In either
>> case I'm not convinced.
>
>
> From a developer perspective, especially when debugging, when we do
> selectMethod("match", ...) and it turns out that this returns the
> default method, it's good to see:
>
>   Method Definition (Class "derivedDefaultMethod"):
>
>   function (x, table, nomatch = NA_integer_, incomparables = NULL,
>       ...)
>   base::match(x, table, nomatch = nomatch, incomparables = incomparables,
>       ...)
>   <environment: namespace:BiocGenerics>
>
>   Signatures:
>           x           table
>   target  "DataFrame" "ANY"
>   defined "ANY"       "ANY"
>
> rather than some obscure/uninformative body. I hope we can keep that.

That was the goal of this patch. We want to keep that, and make
match() ~25% faster when falling back to the default method (for small
inputs). Right now, loading BiocGenerics, IRanges, etc, slows many
functions down by roughly that amount.

>
>>
>>> The implementation of these functions is almost simpler in C than it
>>> is in R, so there is relatively little risk to this change. But I
>>> agree the benefits are also somewhat minor.
>>
>>
>> I don't disagree, but it remains that even calling the C version has
>> costs that should not need to be paid. But maybe we can leave that to
>> the compiler/byte code engine. Optimizing references to symbols
>> resolved statically to name spaces and imports is on the to do list,
>> and with a little care that mechanism should work for foo::bar uses as
>> well.
>
>
> That would be great. Thanks!
>
>
> H.
>
>>
>> Best,
>>
>> luke
>>
>>>
>>>> For other cases if I want to use foo::bar many times, say
>>>> in a loop, I would do
>>>>
>>>> foo_bar <- foo::bar
>>>>
>>>> and use foo_bar, or something along those lines.
>>>>
>>>> When :: and ::: were introduce they were intended primarily for
>>>> reflection and debugging, so speed was not an issue. ::: is still
>>>> really only reliably usable that way, and making it faster may just
>>>> encourage bad practice. :: is different and there are good arguments
>>>> for using it in code, but I'm not yet seeing good arguments for use in
>>>> ways that would be performance-critical, but I'm happy to be convinced
>>>> otherwise. If there is a need for a faster :: then going to a
>>>> SPECIALSXP is fine; it would also be good to make the byte code
>>>> compiler aware of it, and possibly to work on ways to improve the
>>>> performance further e.g. through cacheing.
>>>>
>>>> Best,
>>>>
>>>> luke
>>>>
>>>>
>>>> On Thu, 22 Jan 2015, Peter Haverty wrote:
>>>>
>>>>
>>>>> 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 would you all think about making "::" and ":::" .Primitives?  I
>>>>> have submitted some examples, timings, and a patch to the R bug
>>>>> tracker (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16134).
>>>>> I'd be very interested to hear your thoughts on the matter.
>>>>>
>>>>> Regards,
>>>>> Pete
>>>>>
>>>>> ____________________
>>>>> Peter M. Haverty, Ph.D.
>>>>> Genentech, Inc.
>>>>> phaverty at gene.com
>>>>>
>>>>> ______________________________________________
>>>>> R-devel at r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>
>>>>
>>>> --
>>>> Luke Tierney
>>>> Ralph E. Wareham Professor of Mathematical Sciences
>>>> University of Iowa                  Phone:             319-335-3386
>>>> Department of Statistics and        Fax:               319-335-3017
>>>>    Actuarial Science
>>>> 241 Schaeffer Hall                  email:   luke-tierney at uiowa.edu
>>>> Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
>>>>
>>>>
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpages at fredhutch.org
> Phone:  (206) 667-5791
> Fax:    (206) 667-1319