Re: [S] scope rules

John Maindonald (
Fri, 26 Jun 1998 10:28:13 +1000 (EST)

Jens Oehlschlaegel-Akiyoshi wrote, in response to John Thaden

> in S+ no function has automatic access to any local variables of any
> parent functions FOR SECURITY REASONS (except for objects in frames 0+1).
There must of course be some scoping rules, and what scoping rules]
are at the end of the day preferable is a matter for debate.

The issue of more immediate relevance is that functions ought to be
written with the scoping rules closely in view. They should work within
other functions as well as when entered from the command line.
[The problem arises when the function that is called from within a
function calls a third function, i.e. from within f1 there is a call
to f2, and within f2 there is a call to f3; and f3 needs access to
objects that are local to f1. A similar problem might potentially
arise in f1's call to f2; but then the f1 would not work even when
called from the command line.

Notoriously, many of the modelling functions have not been written
with the scoping rules closely in view. There has been attention to
scoping rules only to the extent that is needed to ensure that they
work when called from the command line. They do not work as
documented when they are called from within another function. The
documentation for such functions should include a warning:
"Special steps, e. g. an assign to frame 1, are needed to make
objects that are local to this function visible when called from
within another function."
Even more helpful would be to document the objects to which this
observation applies.

Even worse, if an object with the relevant name happens to be sitting
around in the working directory, it is that object which function f3
will pick up and use. This means that S-PLUS users who use the
modelling functions from within functions of their own need to be
extremely careful to make visible all objects that functions called by
the modelling function may require. It is also an argument in favour
of keeping our directories free of junk, but which of us do? As for

I have been tempted to say it before, and will say it now. What we
have is basically a beta release of the modelling functions. Users
of the S-PLUS modelling functions have two options - to accept this,
or to give up on the goodies which these functions offer.

As a step to improving the situation, we need one or two carefully
documented good example implementations of modelling functions. A
good place to start might be glm models. These could then be used as
model examples when other modelling functions are written or
rewritten. I expect this will happen sometime. It is necessary, if
S-PLUS is to look forward to healthy maturity and old age, that it
happen very soon. There are people in the S-PLUS community who are
thinking about it. There are pluses as well as minuses in the
situation. The end product will be a lot better than if the start on
such rewriting had happened at an earlier stage.

In summary, the scoping rules we have have pluses and minuses. What
is needed is that the modelling and other code which sits on top has
proper regard to these scoping rules. We need one or two good model
implementations that will demonstrate the issues, dangers, and sorts
of testing to which the code should be robust.

> On Thu, 25 Jun 1998, John Thaden wrote:
> > >Functions defined within functions do not have automatic access to
> > > local variables of the parent.
> > Also, why doesn't a concept as important as scope have an entry in the
> > index of either the S-Plus Programmer's Guide or the User's Guide?


John Maindonald email :
Statistical Consulting Unit, phone : (6249)3998
c/o CMA, SMS, fax : (6249)5549
John Dedman Mathematical Sciences Building
Australian National University
Canberra ACT 0200
This message was distributed by To unsubscribe
send e-mail to with the BODY of the
message: unsubscribe s-news