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]]

