Re: [Rd] R strings, null-terminated or size delimited?

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: Sat, 21 Nov 2009 20:11:29 -0500

On 21/11/2009 7:44 PM, Guillaume Yziquel wrote:
> Duncan Murdoch a écrit :
>>> I believe I should. I'd like the OCaml / R binding to be closely knit
>>> to R internals. One reason would be for speed, the other being that
>>> I'd like to make use of camlp4 to write syntax extensions to mix OCaml
>>> and R syntax. It's therefore important for me not to rely on the R
>>> interpreter to be active when building R values. Or when marshaling R
>>> values via OCaml. There are numerous other issues aside this one.
>> You are probably not going to be able to do that. Take your example of
>> the promise below: to evaluate a promise, you need to evaluate the
>> expression attached to it in the R interpreter. (This is discussed in
>> the R Language Definition.)
>>
>> You can put probably put together simple R objects like integer arrays
>> without having R running, but anything substantial isn't going to be
>> feasible.
>>
>> Duncan Murdoch
>
> That's precisely the issue. I want to map a functional language to a
> functional language. And keep the same evaluation semantics. I do not
> (yet?) see why it should not be feasible.

R is a fairly quirky and irregular language, with lots of functions implemented in C code, so you haven't taken on a small project. But I wish you luck.

Duncan Murdoch

>
> If this is done properly, OCaml could then compile R code natively. That
> would be really nice. There would be other advantages in integrating the
> two languages cleanly.
>
> So, taking the example of promises, I need to map it to its OCaml
> semantic equivalent, which seems to be a Lazy.t structure. That doesn't
> seem (yet) unfeasible.
>
> Thank you for your pointer to the R Language Definition. Starting by R
> Internals was perhaps a bit brutal.
>
> All the best,
>



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sun 22 Nov 2009 - 01:15:10 GMT

This archive was generated by hypermail 2.2.0 : Tue 24 Nov 2009 - 01:40:43 GMT