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?
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]]
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
