[Rd] c(<symbol>, <symbol) |-> expression instead of list

[Martin Maechler]

Dear programmeRs,

I'm proposing and looking into implementing a small change in
R's  c() handling of 'symbol's aka 'name's, and potentially also
'language' parts.

The main motivation is transparent programmatic construction of
expression()s;  and important use cases are expressions used for
"plot math", typically in 
        axis(.., labels = *)   
or    legend(.., legend = *)

[BTW, Paul,  in  grid.legend(*, labels = *),  labels is *not*
 allowed to be an expression]

Look at this code snippet {where the comments include the
results you see} :

e <- expression(a, gamma, nu == 50, x^2 == 3.14, y <- 17, { x[i] <- sin(y^2 + exp(u[i])) })
length(e)
## 6
## Ok, what are the components like ?
##
sapply(e, is.language)
## [1] TRUE TRUE TRUE TRUE TRUE TRUE
## aha, all are  "language",
##
## and specifically :
sapply(e, typeof)
##[1] "symbol"   "symbol"   "language" "language"   "language" "language"
## or in ``S - compatible'' language  {but S+ slightly differs here}:
sapply(e, mode)
##[1] "name" "name" "call" "call" "call" "call"
sapply(e, class)
##[1] "name" "name" "call" "call" "<-"   "{"

Now, in "plotmath" situations,
you'd often want the '50' , '3.14' or '17'  be the content of
other R variables, and so we need  substitute()  or  bquote(),
and these directly result in "name" or "language" objects :

However, you cannot very easily concatenate them to an
expression:

z <- c(88, 143)
(e1 <- substitute(x[1]^2 == v, list(v = z[1])))
(e2 <- bquote(pi / r[i]^2 == .(z[2])))

## However,
c(e1, e2)  ## is a list, not an expression ...
## but 
plot(1, type="n")
legend("top",    legend= c(e1,e2)) ## is ugly (no super/sub scripts ...)
legend("center", legend=
       c(as.expression(e1),
         as.expression(e2)))# works but is a bit cumbersome

-------------

So now, my proposition is to make the  "as.expression()"
implicit in  c(),
since the  help file for c() does mention that

>      The output type is determined from the highest type of the
>      components in the hierarchy NULL < raw < logical < integer < real
>      < complex < character < list < expression. .....

and implicitly,  "symbol" and "language" are treated  by as.list()
rather than as expression-like.

I would like to change this, i.e.,  c() should  result in
"expression" rather than "list"  when it's applied to symbola
and language types.

Note that S-plus 8.0.4, and 3.4 does this very differently
anyway.

Martin Maechler, ETH Zurich