R strings, null-terminated or size delimited?

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/