Simon Urbanek a ?crit :
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
Hi. Concerning tryEval, I had a look at context.c, and it says:
/* This is a simple interface for evaluating R expressions from C with a guarantee that one will return to the point in the code from which the call was made (if it does return at all). This uses R_TopleveExec to do this. It is important in applications that embed R or wish to make general callbacks to R with error handling. It is currently hidden with a data structure definition and C routine visible only here. The R_tryEval() is the only visible aspect. This can be lifted into the header files if necessary. (DTL) R_tryEval is in Rinternals.h (so public), but not in the API. */
Now, here's a feature I'd like to implement with the API: In OCaml, there's a library called Lwt. It's a library implementing lightweight, or green, threads. The idea is the following: Suppose I have to evaluate f (). I do: let lwt_f = Lwt.return (f ()). Now, I want to evaluate g (f ()). I write: let lwt_g = lwt_f >>= (function x -> Lwt.return (g x)). This might seem overly complicated, and it somehow is. The interesting point is this ">>=" operator. Because it allows to compose two (or more) computations, and it does context commutations. So this implements threads in a cooperative way, all running in one single real thread. What I want to do is to be able to launch some R code, and have it multithread with other OCaml code, within one single real thread. Therefore I have to implement the commutation context somewhere in the evaluation mechanism of R itself. The API doesn't support that, I guess.
Guillaume Yziquel http://yziquel.homelinux.org/