4 ms·
No fundamental reason I know of that the C libraries for R could be used with Racket as well. After all, both R and Racket are able to do the FFI dance. Could t
by peatmoss 9y ago
No fundamental reason I know of that the C libraries for R could be used with Racket as well. After all, both R and Racket are able to do the FFI dance. Could the hypothetical R-in-Racket implementation sufficiently mimic the R FFI as to allow all R code to run without modification? Probably, maybe?
- peatmoss 9y ago* could not be used
- int_19h 9y agoThat's exactly the problem. R has a very specific API for its extensions - it's not just vanilla C, it's stuff like SEXP. Although now that I think more about it, it's not quite as bad as Python, because the data structures are mostly opaque pointers (at least until someone uses USE_RINTERNALS - which people do sometimes, even though they're not supposed to), so all operations have to be done via functions, where you can map them accordingly. You'd also need to emulate R's object litetime management scheme with Rf_protect etc; but that shouldn't be too difficult, either. Some more reading on all this: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#System-and-foreign-language-interfaces https://cran.r-project.org/doc/manuals/r-release/R-exts.html... http://adv-r.had.co.nz/C-interface.html http://adv-r.had.co.nz/C-interface.html
- peatmoss 9y agoOh, yeah, now that you mention it I have seen the SEXP and protect / unprotect stuff before. Maybe a hybrid approach of porting some of the core stuff / popular libraries to Racket's FFI would be more ideal if one were to do this for real. Maybe aiming for "mostly compatible, with some porting work for a handful of the more popular non-R (C, Rcpp) packages would yield a better result in the end.