From maechler at stat.math.ethz.ch  Thu Aug 27 14:19:50 2009
From: maechler at stat.math.ethz.ch (Martin Maechler)
Date: Thu, 27 Aug 2009 14:19:50 +0200
Subject: [Rd] c(<symbol>, <symbol) |-> expression instead of list
In-Reply-To: <971536df0908270432x69c0daa5oa52d1ee3426c0655@mail.gmail.com>
References: <1251232240.5919.5.camel@ubuntu.une.net.co>
	<0366B624-A934-4949-98FF-3EAE569C95EC@comcast.net>
	<6F4FD737-25F9-4DE6-98AA-F4185BC34650@comcast.net>
	<1251239164.5919.7.camel@ubuntu.une.net.co>
	<19094.17411.805111.923613@lynne.math.ethz.ch>
	<19094.23924.888966.900424@lynne.math.ethz.ch>
	<971536df0908270432x69c0daa5oa52d1ee3426c0655@mail.gmail.com>
Message-ID: <19094.31206.341334.14077@lynne.math.ethz.ch>

>>>>> "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)



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