4 ms·

It's true, the more I do in R, the more I wish that it had remained scheme compatible (originally, R was built on a scheme if I remember correctly). My someday

It's true, the more I do in R, the more I wish that it had remained scheme compatible (originally, R was built on a scheme if I remember correctly). My someday project is `#lang arcket` for Racket, which would allow people to use existing R code, and mix with Racket, with appropriate data.frame data structures and whatnot.

int_19h 9y ago
The problem will likely be similar to that with alternative Python implementations - because so many existing libraries in the ecosystem are written in C, an implementation that is not ABI-compatible with them is not attractive to most existing users.
- 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 ago
    That'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 ago
      Oh, 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.

int_19h 9y ago

The problem will likely be similar to that with alternative Python implementations - because so many existing libraries in the ecosystem are written in C, an implementation that is not ABI-compatible with them is not attractive to most existing users.

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 ago
  That'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 ago
    Oh, 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.