From simon.urbanek at r-project.org  Wed Apr  1 22:21:53 2009
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Wed, 1 Apr 2009 16:21:53 -0400
Subject: [Rd] Assignment to string
In-Reply-To: <8b356f880904011249r7e68bc12jd57ce226c8daf996@mail.gmail.com>
References: <8b356f880904011249r7e68bc12jd57ce226c8daf996@mail.gmail.com>
Message-ID: <EE175D00-B63F-484F-B596-A974A2305423@r-project.org>


On Apr 1, 2009, at 15:49 , Stavros Macrakis wrote:

> The documentation for assignment says:
>
>     In all the assignment operator expressions, 'x' can be a name or
>     an expression defining a part of an object to be replaced (e.g.,
>     'z[[1]]').  A syntactic name does not need to be quoted, though it
>     can be (preferably by backticks).
>
> But the implementation allows assignment to a character string (i.e.  
> not a
> name), which it coerces to a name:
>
>         "foo" <- 23; foo
>         # returns 23
>> is.name("foo")
>         [1] FALSE
>
> Is this a documentation error or an implementation error?
>

Neither - what you're missing is that you are actually quoting foo  
namely with double-quotes. Hence both the documentation and the  
implementations are correct. (Technically "name" as referred above can  
be either a symbol or a character string).

Cheers,
Simon


> The coercion is not happening at parse time:
>
>    class(quote("foo"<-3)[[2]])
>    [1] "character"
>
> In fact, bizarrely, not only does it coerce to a name, it actually
> *modifies* the parse tree:
>
>> gg <- quote("hij" <- 4)
>> gg
>    "hij" <- 4
>> eval(gg)
>> gg
>    hij <- 4
>
> *** The cases below only come up with expression trees generated
> programmatically as far as I know, so are much more marginal cases.  
> ***
>
> The <- operator even allows the left-hand-side to be of length > 1,  
> though
> it just ignores the other elements, with the same side effect as  
> before:
>
>> gg <- quote(x<-44)
>> gg[[2]] <- c("x","y")
>> gg
>    c("x", "y") <- 44
>> eval(gg)
>> x
>    [1] 44
>> y
>    Error: object "y" not found
>> gg
>    x <- 44
>
> None of this is documented in ? <-, and it is rather a surprise that
> evaluating an expression tree can modify it.  I admit we had a feature
> (performance hack) like this in MacLisp years ago, where expanded  
> syntax
> macros replaced the source code of the macro, but it was a documented,
> general, and optional part of the macro mechanism.
>
> Another little glitch:
>
>    gg <- quote(x<-44); gg[[2]] <- character(0); eval(gg)
>    Error in eval(expr, envir, enclos) :
>      'getEncChar' must be called on a CHARSXP
>
> This looks like an internal error that users shouldn't see.
>
>           -s
>
> 	[[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>



[Rd] Assignment to string
Simon Urbanek