From luke at stat.uiowa.edu  Sun Oct 26 20:38:57 2008
From: luke at stat.uiowa.edu (Luke Tierney)
Date: Sun, 26 Oct 2008 14:38:57 -0500 (CDT)
Subject: [Rd] changed behaviour of 'get' in 2.8.0: request for unchange
In-Reply-To: <62C82B39B8A85E4B95A18F7F7B852F870C6FE1A8@exvic-mbx03.nexus.csiro.au>
References: <62C82B39B8A85E4B95A18F7F7B852F870C6FE1A2@exvic-mbx03.nexus.csiro.au>
	<Pine.LNX.4.64.0810240538130.16171@itasca2.wildberry.org>,
	<971536df0810240427m4bd50c8ake19feec865c747fd@mail.gmail.com>
	<62C82B39B8A85E4B95A18F7F7B852F870C6FE1A8@exvic-mbx03.nexus.csiro.au>
Message-ID: <alpine.LFD.2.00.0810261421010.2728@nokomis.stat.uiowa.edu>

On Sat, 25 Oct 2008, Mark.Bravington at csiro.au wrote:

> Thanks both
>
>> The other item that might have a relationship to this
>> is the ability to a copy an object without evaluating it.  This can't be
>> done entirely in R but can be done in C code from R:
>> http://tolstoy.newcastle.edu.au/R/e2/devel/07/09/4444.html
>
>> For me, copying is even more important than inspecting and that seems
>> to be for Mark's case too.
>
>
> Gabor's point is spot-on for me (at least, for the first problem I ran across). I really do need to store a value (possibly an R_MissingArg token), temporarily overwrite it with some other value, then later restore it to whatever condition it was in before. There's no evaluation prior to restoration. In fact, given the context I'm doing this in, it would be good if I could also copy an active-binding or a delayed-eval *without* forcing them-- hadn't thought of that. So Gabor's copy-without-forcing would elegantly solve my (first) problem.
>
>> If your code is relying on this behavior then it would be a good idea
>> to have a look at your code and figure out why, as there is very
>> little useful that can be done with this missing arg token.  If after
>> that it turns out that there is a need to be able to test for whether
>> a binding represents a missing value then we can look into adding a
>> function that tests for this.  There is already sone desire to have a
>> way of checking whether a binding contains a delayed evaluation, so
>> maybe something like a function bindingStatus that returns one of
>> "active", "missing", "delayed" or "evaluated" makes sense.
>
> It would also be great to have 'bindingStatus'. One context is in the 'debug' package-- you can imagine the sort of shenanigans that goes on inside that. I've been considering re-introducing a watch window, now that there's an excellent 'SetTimeLimit' function to pre-empt problems, but I don't want to force promises or activate bindings just because an argument variable has been added to the watch list.

I'll look into both -- will probably be a couple of weeks before I get
to it though.

>
> BTW: re the bug ("Returning the internal R_MissingArg token was a bug."). Is the bug that 'get' should force evaluation, or is it that the R_MissingArg is a "naked singularity"? I ask because presumably the token will still be "legally" available via e.g. 'formals( function(x) NULL)$x'.

My reading of the docs is that evaluating get('x') should be
equivalent to evaluating x (not that this is explicit but I think it
is a reasonable inference -- also, for what it is worth, this is true
in Splus).  Also the missing value token is an internal implementation
approach that we might want to change later -- the fact that it
doesn't print sensibly makes it clear that is isn't meant to be
visible.

The fact that the same tokes is used in formals with no default value
is somewhat conincidental (but helpful at the moment as it provides at
least one means of determining whether an argument has a default, but
one has to be very careful indong so).  This should also be handled
differently.  Splus seems to use a separate token but also with
somewhat peculiar behavior.  Something along the lines of returning
NULL for no default but providing a query mechanism to distinguish
really no default from a default of NULL would be cleaner, but
designing something sensible here is a bit harder so probably won't
happen soon.  In codetools and my compiler code I try to isolate
anything that depends on missing defaults in one or two functions so
there isn't much to fix if this changes.

luke

>
> NB also that there are one or two other things that can legitimately be done to a Missing object, e.g. object.size.  A number of my documentation examples were broken by the 'get' change for this kind of reason-- it was late last night when I fixed them, and I now can't remember what they all were.
>
> Ah well. I had a nasty feeling somebody might say "we are going to fix the other accessors too" since I have just managed to use them to work around the new behaviour of 'get'. I almost didn't send the original email, for that reason...
>
> Mark
>

-- 
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] changed behaviour of 'get' in 2.8.0: request for unchange
Luke Tierney