From luke at stat.uiowa.edu  Sat Apr 19 15:49:51 2008
From: luke at stat.uiowa.edu (Luke Tierney)
Date: Sat, 19 Apr 2008 08:49:51 -0500 (CDT)
Subject: [Rd] Pb with package::foo(x) <- value
In-Reply-To: <alpine.LFD.1.10.0804190640050.18033@gannet.stats.ox.ac.uk>
References: <48095636.2040500@fhcrc.org>
	<alpine.LFD.1.10.0804190640050.18033@gannet.stats.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.0804190832460.3041@itasca2.wildberry.org>

On Sat, 19 Apr 2008, Prof Brian Ripley wrote:

> On Fri, 18 Apr 2008, Herve Pages wrote:
>
>> Hi,
>>
>> The parser doesn't seem to like this:
>>
>>   somePackage::foo(x) <- value
>>   somePackage:::foo(x) <- value
>>
>> where foo() is a replacement function or method defined in package
>> somePackage.
>
> But the error message you show is not from the parser, and
>
>> parse(text="somePackage:::foo(x) <- value")
> expression(somePackage:::foo(x) <- value)
> attr(,"srcfile")
> <text>
>
> does work. The error you show arises is in the evaluator.
>
> That's because that is not legal code.  :: and ::: are operators, not part
> of the language per se (although I have proposed changing that).  The
> message comes at a check for a name, and base::length is not a name.

It would be nice to be able to handle this some way.  Kurt and I have
discussed this off and on, but not come up with a good approach.  In
principle incorporating :: and ::: into the language more directly
might be a good idea but I'm not sure how many things this would
break.  Pragmatically it may be more feasible to modify the complex
assignment code to deal with a call of the form

     ::(somePackage,foo)(x) <- y

which is essentially what somePackage:::foo(x) <- value is parsed
into.  Even there I am a bit nervous at adding to an already fairly
hairy piece of code.

There are some potential subtleties though:  In the evaluation of

    somePackage:::foo(bar(x)) <- value

one deeds to call both somePackage:::foo and somePackage:::foo<-.
Just because foo is defined in package X does not necessarily mean
foo<- is also deined in package X.  Not a very likely scenario, but
the sort of thing one needs to think through (and there may be a few
others I haven't thought of).

I would advise against ever calling an assignment function directly
unless you really know what you are doing.  The complex assingment
process does some initial setup, including checking for the need to
duplicate the object to be modified and duplicating if needed. That
gets lost with a direct call.  Many internal assignment functions also
make the duplication check but there are a few that don't (in a most
cases that is probably an oversight but I believe it is deliberate in
a few).

Best,

luke

>
> It often helps to look error messages up in the sources.
>
>
>> For example:
>>
>>  > x <- integer(4)
>>  > base::length(x) <- 7
>>   Error in base::length(x) <- 7 : invalid function in complex assignment
>>
>> I've tried to put some back quotes on the left side of the assignment in
>> different ways but was not successful. So finally I had to use the
>> non-replacement form:
>>
>>  > x <- base::`length<-`(x, 7)
>>  > x
>>   [1]  0  0  0  0 NA NA NA
>>
>> Is there a way to avoid this?
>>
>> Thanks!
>> H.
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
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 at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu



[Rd] Pb with package::foo(x) <- value
Luke Tierney