s-news
[Top] [All Lists]

[S] Re: scope rules

To: "'S-NEWS'" <s-news@wubios.wustl.edu>
Subject: [S] Re: scope rules
From: Mark Bravington FSMG CEFAS <M.V.BRAVINGTON@cefas.co.uk>
Date: Mon, 29 Jun 1998 11:54:12 +0100
Alternate-recipient: Allowed
Sender: owner-s-news@wubios.wustl.edu
X400-content-type: P2-1984 (2)
X400-mts-identifier: [/PRMD=MAFF400/ADMD=ATTmail/C=GB/;LOWNTG-980629095412Z-698]
X400-originator: M.V.BRAVINGTON@cefas.co.uk
X400-received: by mta parker in /PRMD=MAFF400/ADMD=ATTmail/C=GB/; Relayed; Mon, 29 Jun 1998 10:37:48 +0100
X400-received: by mta scott in /PRMD=MAFF400/ADMD=ATTmail/C=GB/; Relayed; Mon, 29 Jun 1998 10:52:15 +0100
X400-received: by mta lowntg in /PRMD=MAFF400/ADMD=ATTmail/C=GB/; Relayed; Mon, 29 Jun 1998 11:54:12 +0100
X400-recipients: non-disclosure:;
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
m.v.bravington@cefas.co.uk
-----------------------------------------------------------------------
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

<Prev in Thread] Current Thread [Next in Thread>