[Rd] PROTECT and OCaml GC.

Simon Urbanek simon.urbanek at r-project.org
Mon Nov 30 15:15:08 CET 2009


Guillaume,

On Nov 29, 2009, at 13:57 , Guillaume Yziquel wrote:

> Simon Urbanek a écrit :
>> On Nov 28, 2009, at 7:50 PM, Guillaume Yziquel wrote:
>> FWIW what I think you should be really looking at is  
>> R_PreserveObject/R_ReleaseObject.
>
> OK. Thanks.
>
>> I would suggest looking at the many other R embeddings in other  
>> languages that already exist since I don't think you approach is  
>> very viable (but I think I expressed that already before).
>
> Lisp - the only thing I've seen is a translator:
>
> http://dan.corlan.net/R_to_common_lisp_translator/
>
> I haven't found a binding for Haskell. Nor for Scheme.
>
> Do you know of any bindings of R to functional languages?
>
>> since I don't think you approach is very viable (but I think I  
>> expressed that already before).
>
> You expressed the sentiment that it would be a very bad idea to  
> bypass the current API. I would be happy to hear why you would think  
> that a low-level binding is not possible, or not very viable.
>
> By low-level, I mean a binding that takes hold of R objects without  
> using symbols all over to reference them. (Using symbols in the  
> formals, the body or the environment of a closure is fine, for  
> instance, but I'd like to execute a closure directly, and eventually  
> be able to construct R closure from OCaml functions).
>

You're talking about two entirely different things -- bypassing the  
API is a very bad idea, but it has nothing to do with your last  
paragraph. The API gives you access all user-visible aspects of R  
which is all you really need for any embedding -- that includes  
closure body, evaluation etc. I see no reason why you should ever go  
lower than the API since that is unreliable and unsupported and thus  
you won't get any help with that (that is IMHO the main reason why you  
get no responses here - and I wouldn't expect any). All other  
functions are hidden on purpose since they cover internal aspects that  
should not be relied upon.

So again, I just think you're operating on the wrong level here -- and  
this has nothing to do with the fact that you're binding to a  
functional language since the mechanisms are the same regardless of  
the languages (that's why Omegahat was used to bind into any random  
language that seemed useful). You get more headaches since you have to  
decide how to handle closures both ways, but I suspect the practical  
solution is to use evaluators on the side where the function is  
defined (especially for the R side since it includes non-S-language  
code so you simply cannot map it).

If you have suggestions for extending the API, feel free to post them  
with exact explanations how in general that extensions could be useful  
(general is the key word here - I think so far it was rather to hack  
around your way of implementing it). [And FWIW tryEval *is* part of  
the API].

Cheers,
Simon


> Please elaborate on the difficulties you perceive. That would be  
> helpful.
>
>> Cheers,
>> Simon
>
> All the best,
>
> Guillaume.
>
> -- 
>     Guillaume Yziquel
> http://yziquel.homelinux.org/
>
>



More information about the R-devel mailing list