Skip to content
Prev 22357 / 398502 Next

variable scope

Bill.Venables at cmis.csiro.au writes:
On the other hand, it is part of the language design to make these
things possible if you must have them. And there are a few places
where things must be by reference (actually, they are "by name", I
believe) in order to keep the "everything is done with functions"
paradigm. The "<-" function is one obvious example. And of course the
access to unevaluated expressions is utilized all over, for plot
labels and in the update() mechanisms, etc.

However, Bill's point is valid. There are several places where
these facilities have been used and later regretted by the designers.

This happens especially where we attempt to be user-friendly and allow
syntax that is not really consistent with the semantics. Notice for
instance the inconsistency between help(lm) and apropos("lm") and the
non-functioning of myhelp<-function(foo){help(foo)}. The help is not a
property of the object, but of the name of the object.

Another example that has come back to haunt us several times is
lm(...,data=d,offset=foo). The problem is that we want "foo" to be
found inside "d" if present, but call-by-value semantics imply that it
is an object in the caller's scope. You really ought to pass the name
"foo" (or maybe better: quote(foo), or a formula ~foo).

Also, it is tricky to get things exactly right, for example you can
not just fix(myfamily$linkfun).