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

luke-tierney at uiowa.edu luke-tierney at uiowa.edu
Fri Jan 23 16:01:24 CET 2015


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.

> 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.

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
>

-- 
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



More information about the R-devel mailing list