[S] Re: scope rules

Mark Bravington FSMG CEFAS (M.V.BRAVINGTON@cefas.co.uk)
Mon, 29 Jun 1998 11:54:12 +0100

It seems to me that there is an impasse over scoping rules in S: they are horrible, but we are stuck with them because so many functions have been written under the existing framework. I have speculated about a work-round that preserves compatibility, given a slight change to the evaluator. The idea would be to allow you to write new functions that follow R scope rules, but to allow existing functions to follow the usual S rules. Over time, there could be a gradual migration to more practical rules. But perhaps this is a recipe for disaster, rather than a panacea?

The trick would be to use the "frame.attr" facility to tell Splus that the current function wants to use R-like scoping rules. Suppose the evaluator can't find variable "x" in the current frame. If the current frame has an attribute "Rscope", then the evaluator would start its search for variables in the parent frame; otherwise, it would start in frame 1. This would operate recursively; if "x" doesn't exist in the parental frame either, but the parental frame has an "Rscope" attribute, then the evaluator would look at the grandparent, etc. Whenever the ancestor doesn't have an "Rscope" attribute, the search order switches to frame 1, frame 0, and the permanent directories as per normal.

Frame attributes are set automatically when a function is called, to equal the attributes of the function itself. So a function "f" could be made to follow R scoping by just calling

> attr( f, 'Rscope') <- T

Something would need to be done about functions like "lapply", which at present create "orphan" frames of the functions they invoke. IE if you call "sys.parent()" from any function invoked by "lapply", you will always get the answer1. This destroys the calling hierarchy. I don't see a good reason for this, but there might be compatibility problems if this were changed.

The recurrent problems with modelling functions are just embarrassing for S; the lack of nested functions is vexing (see my previous post); and the use of frame 1 is an abomination. Is the above worth pursuing, or is there a snag?

Mark Bravington
This message was distributed by s-news@wubios.wustl.edu. To unsubscribe
send e-mail to s-news-request@wubios.wustl.edu with the BODY of the
message: unsubscribe s-news