From hpages at fredhutch.org  Fri Jan 23 19:11:47 2015
From: hpages at fredhutch.org (=?windows-1252?Q?Herv=E9_Pag=E8s?=)
Date: Fri, 23 Jan 2015 10:11:47 -0800
Subject: [Rd] :: and ::: as .Primitives?
In-Reply-To: <alpine.LFD.2.11.1501230857400.10879@itasca.stat.uiowa.edu>
References: <CAGh0NYotjwDf5JYGcTggJWhWUSVsmBAuhbtGzwqsO+nXBpthyQ@mail.gmail.com>	<alpine.LFD.2.11.1501221330230.10879@itasca.stat.uiowa.edu>	<CAOQ5NycWpawep=tFCEkVRbU-Hy-asCUowaQF9a1H41d5z7Owfw@mail.gmail.com>
	<alpine.LFD.2.11.1501230857400.10879@itasca.stat.uiowa.edu>
Message-ID: <54C28EE3.8070305@fredhutch.org>

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.

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



[Rd] :: and ::: as .Primitives?
=?windows-1252?Q?Herv=E9_Pag=E8s?=