John Chambers writes:
>>
>> Not internals of the evaluator, the .environment class.
>> Something like:
>>- move the .self into a super-class of envRefClass (in this case
>> .environment),
>>- make the method for `...@` for .environment, such that any update of the
>>slots of the ob
On 10/24/10 1:43 PM, Vitalie S. wrote:
John Chambers writes:
On 10/24/10 2:53 AM, Vitalie S. wrote:
Thank you for the answer, John.
John Chambers writes:
Second point first: The actual environment of a function is tightly
bound to low-level implementation at the C level. Only a _real
John Chambers writes:
> On 10/24/10 2:53 AM, Vitalie S. wrote:
>>
>> Thank you for the answer, John.
>>
>> John Chambers writes:
>>> Second point first: The actual environment of a function is tightly
>>> bound to low-level implementation at the C level. Only a _really_
>>> strong practical ar
On 10/24/10 2:53 AM, Vitalie S. wrote:
Thank you for the answer, John.
John Chambers writes:
Second point first: The actual environment of a function is tightly
bound to low-level implementation at the C level. Only a _really_
strong practical argument would even tempt us to change that, su
Thank you for the answer, John.
John Chambers writes:
> Second point first: The actual environment of a function is tightly
> bound to low-level implementation at the C level. Only a _really_
> strong practical argument would even tempt us to change that, such as by
> going away from the re
For reference classes (and other R code) it's important to distinguish
the application program interface from the implementation. Anyone is
welcome to explore the implementation, but we reserve the right to
change that, particularly with a new feature in the language.
The draft API for refer
