Re: [Rd] c(symbol, symbol) |- expression instead of list
On Thu, Aug 27, 2009 at 6:18 AM, Martin
Maechlermaech...@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 ...
although as.expression(c(e1, e2)) is an expression.
plot(0)
legend(top, as.expression(c(e1, e2)))
in light of which the savings is just one as.expression().
Another possibility would be to add support for
multiple arguments to bquote:
plot(0)
legend(top, bquote(x[1]^2 == .(z[1]), pi / r[i]^2 == .(z[2])))
Then we would not need to use c() in the first place.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] c(symbol, symbol) |- expression instead of list
GaGr == Gabor Grothendieck ggrothendi...@gmail.com
on Thu, 27 Aug 2009 07:32:42 -0400 writes:
GaGr On Thu, Aug 27, 2009 at 6:18 AM, Martin
GaGr Maechlermaech...@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)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] c(symbol, symbol) |- expression instead of list
On Thu, Aug 27, 2009 at 8:19 AM, Martin
Maechlermaech...@stat.math.ethz.ch wrote:
GaGr == Gabor Grothendieck ggrothendi...@gmail.com
on Thu, 27 Aug 2009 07:32:42 -0400 writes:
GaGr On Thu, Aug 27, 2009 at 6:18 AM, Martin
GaGr Maechlermaech...@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.
But that is already how quote() works, i.e. it can return objects
of different classes so that would not be unexpected.
GaGr Then we would not need to use c() in the first place.
(in that use case, yes)
Another possibility is to create equote() which would be like a multi-argument
bquote but consistently produces an expression. That would be more
convenient than writing c(bquote(...), bquote(...))
Note that nothing here prevents the c() enhancement to be done as well.
The two approaches are independent.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
