[R] combining mathematical notation and value substitution

[Thomas Lumley]

On Thu, 26 Jun 2003, Faheem Mitha wrote:

>
> Hmm. I'm trying to distinguish in my mind the value of an expression and
> the expression itself. For some reason it reminds me of the following
> exchange, from "Through the Looking-Glass".
>

Yes, but Carroll gets that slightly wrong: the song is not "A-sitting On a
Gate", (which is an English phrase, not a song).



> >
> > > thing <- quote("Monotonic Multigamma Run ("*n==len* ", " * theta
> > ==t1*").")
> > > mode(thing)
> > [1] "call"
> > > length(thing)
> > [1] 3
> > > thing[[1]]
> > ==
> > > thing[[2]]
> > "Monotonic Multigamma Run (" * n == len * ", " * theta
> > > thing[[3]]
> > t1 * ")."


> > So it is a call to ==, with two arguments, each itself a call.  The first
> > arguemetn is also a call to == and the second is a call to *. And so on in
> > a tree structure.
>
> This is very interesting. I had convinced myself that an expression could
> not become a call unless created explicitly by call, because it could not
> know out of all the possible call structures which one to turn the
> expression into. However, it appears this is not the case. So, naturally,
> this makes me wonder, what rules are used to make the structure, out of
> all the various possibilities. For example, the function in the call could
> have corresponded to one of the *'s, and then the rest of the structure
> would have been different. And is this rule part of the language
> definition?
>

The rules are defined by the R grammar, which can be found in
src/main/gram.y (if you speak bison)

Basically, == has lower precedence than *, so one of the == must be the
last function called.  This is necessarily part of the language
definition, as it tells you the meaning of eg
  2*3==6
Since * has higher precedence this is parsed as (2*3)==6, not 2*(3==6).

It doesn't actually matter which == comes first, but we can see from other
examples that the rightmost operator ends up at the root of the tree
Since
> 2<3<4
[1] TRUE
it must have been evaluated as (2<3)<4,  not 2<(3<4)



While the rules for constructing the tree are part of the language
definition, the order of evaluation might not be.  In C, for example, the
order of evaluation is not specified except to the extent that precedence
constrains it (and for a few special operators like && and ||).

FOr an R example, if you do
	f(plot(a), plot(b))

it is clear that the plot commands must be evaluated before f() returns if
their return values are actually used. It is not clear which order the
plots() appear, and I would say that it shouldn't be part of the language
definition.


	-thomas