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

[Martin Maechler]

>>>>> "GaGr" == Gabor Grothendieck <ggrothendieck at gmail.com>
>>>>>     on Thu, 27 Aug 2009 07:32:42 -0400 writes:

    GaGr> On Thu, Aug 27, 2009 at 6:18 AM, Martin
    GaGr> Maechler<maechler at stat.math.ethz.ch> wrote:
    >> 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 ...

    GaGr> although as.expression(c(e1, e2)) is an expression.

    GaGr> plot(0)
    GaGr> legend("top", as.expression(c(e1, e2)))

    GaGr> in light of which the savings is just one as.expression().

That's correct.
But my main point is that it's unnatural that
an expression is "list-like" with components "language"
and when I use  c() on these language-parts I don't get back the
expression.


    GaGr> Another possibility would be to add support for
    GaGr> multiple arguments to bquote:

    GaGr> plot(0)
    GaGr> legend("top", bquote(x[1]^2 == .(z[1]), pi / r[i]^2 == .(z[2])))

well, that would solve the use case I gave, 
but would actually result in making  bquote() return
*either* a 'language'/'symbol'  *or*  an 'expression';
which is called polymorphic behavior and often can be slightly
confusing/complicating.

    GaGr> Then we would not need to use c() in the first place.

(in that use case, yes)