On Jul 9, 2011, at 00:17 , Michael Lawrence wrote:
> On Thu, Jun 30, 2011 at 9:35 AM, Duncan Murdoch
> <murdoch.dun...@gmail.com>wrote:
>
>> On 29/06/2011 9:09 PM, Michael Lawrence wrote:
>>
>>> Hi guys,
>>>
>>> Looks like mkCLOSXP cannot handle external pointers as the function body.
>>> Work around is obvious, but I guess it's a bug nonetheless.
>>>
>>
>> I don't know if it's a bug. The mkCLOSXP code has a list of types that it
>> accepts; external pointers and environments aren't in that list, so you get
>> the same error you saw with
>>
>> fun<- eval(substitute(function() x, list(x = environment())))
>>
>> There's a comment
>>
>> /* This is called by function() {}, where an invalid
>> body should be impossible. When called from
>> other places (eg do_asfunction) they
>> should do this checking in advance */
>>
>>
>> I don't know whether there's any reason for the restriction, but I'd want
>> to look closely at what gets done with the body to make sure that putting an
>> environment or external pointer or other weird type there doesn't cause
>> other problems.
>>
>>
> Ok, well if this is user error, then the error message should not ask the
> user to report it as a bug. The comment cited above is incorrect, since it
> is indeed possible to give function() an incorrect body.
Yes. Of course, the message predates certain object types, so things may have
gotten out of sync.
I don't actually see why is would be a problem to allow any (user-visible)
object as the body of a function. All that happens is that the return value of
the function would be that object, no?
There was at some point a push towards regularizing the language, and these
checks may be a relic of that.
(The current code is "svn blame"d to me, but it was a branch update in
Dec.1999, and I can't really be bothered to go find out on which branch it
happened on and who did it. Besides, the wench is dead...)
--
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd....@cbs.dk Priv: pda...@gmail.com
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
