Duncan Murdoch a écrit :

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

I've got code that does basic things. It relies essentially on tryEval. But I have issues with the typing system. Let me explain on a rather simple example. (Please keep in mind that OCaml typing is polymorphic, somehow in the spirit of C++ template types).

I have implemented an OCaml function that is of type

        val R.force : 'a Lazy.t R.t -> 'a R.t

Wich means that it takes as first argument a R value, that denotes an 'a Lazy.t value in OCaml. An 'a Lazy.t value is basically what you would call a promise, promising to deliver a value of type 'a.

And 'R.force p' would evaluate to an R value denoting an OCaml value of type 'a.

Basically, this R.t type is a polymorphic type whose semantics would hopefully be to be an isomorphism between R values and OCaml types.

But R forces promises recursively. This means that if x is the promise of a promise in R, x would be of type 'a Lazy.t Lazy.t R.t.

Forcing it in R would give a value which should be of type 'a t.

However, OCaml typing is static typing. Which means it does not keep track of typing at runtime. It relies only on static typing.

So, logically, OCaml would believe 'R.force x' to be of type 'a Lazy.t R.t. Which is inconsistent with R semantics. This screws up the typing system of OCaml, and segfaults are therefore close nearby.

So this is a simple example of why I would need to go into the nitty gritty details of R code. To see how to slowly map R semantics into OCaml.

But I have another issue, which is basically that I'd like to follow the code of the eval function, because there are LANGSXP which I can evaluate, and others which fails miserably. From my wrapping of the quantmod library:

# getSymbols "YHOO";;
Erreur dans as.character(sc[[1]]) : cannot coerce type 'closure' to vector of type 'character'
Exception: Failure "OCaml-R error in r_eval_sxp C stub.".

The R error message is rather obscure to me.

That's why I'd like to write some stub code around, say, the promiseArgs and the applyClosure functions, so that I could test them with different values in OCaml's interactive toplevel.

Unfortunately, or fortunately, (depends on the point of view), I've looked at symbols of libR.so (I'm on a Debian box, with Debian R), and I fail to see such symbols exported.

How could I get to bind to these functions, without having to compile my stuff and R at the same time?

All the best,

--
     Guillaume Yziquel
http://yziquel.homelinux.org/

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to