From tlumley at u.washington.edu  Wed Sep  6 00:54:45 2006
From: tlumley at u.washington.edu (Thomas Lumley)
Date: Tue, 5 Sep 2006 15:54:45 -0700 (PDT)
Subject: [Rd] (PR#9202) Re: Bugs with partial name matching
In-Reply-To: <Pine.LNX.4.64.0609051507530.17674@homer23.u.washington.edu>
References: <20060905014002.634C928F8E@slim.kubism.ku.dk>
	<Pine.LNX.4.64.0609051507530.17674@homer23.u.washington.edu>
Message-ID: <Pine.LNX.4.64.0609051542310.17674@homer23.u.washington.edu>

On Tue, 5 Sep 2006, Thomas Lumley wrote:

>
> The partial matching is fairly deeply built in to complex assignment,
<sip>
> because as evalseq works through the nested calls on the LHS the code
> being called doesn't know it is in an assignment call.


The problem in
> D = list(ABCD=2:1)
>  D$ABC[]<-3:4
> D
$ABCD
[1] 3 4

$ABC
[1] 3 4

is that eval.c:evalseq ends up with a reference to D$ABCD from evaluating 
D$ABC with partial matching.  Since evalseq doesn't (and shouldn't) 
increase NAMED on these partially evaluated calls, NAMED is still 1 for 
D$ABCD.  When evalseq's D$ABC has 3:4 assigned into it the vector is 
changed directly, since NAMED=1, and both D$ABC and D$ABCD change.

The minimal fix would appear to be the horrible hack of incrementing NAMED 
whenever a list element is even looked at with partial matching. Otherwise 
evalseq would have to be taught to recognize aliasing from partial 
matching.


 	-thomas




[Rd] (PR#9202) Re: Bugs with partial name matching
Thomas Lumley