From: "Bünzli Daniel" <daniel.buenzli@erratique.ch>
To: Maxence Guesdon <maxence.guesdon@inria.fr>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] R bindings ?
Date: Sun, 16 Mar 2008 22:24:19 +0100 [thread overview]
Message-ID: <9CECF824-9C61-48A9-809C-D2B152F0EBD3@erratique.ch> (raw)
In-Reply-To: <20080316200146.vgd0u64rw4gcckwg@pops-rocq.inria.fr>
Le 16 mars 08 à 20:01, Maxence Guesdon a écrit :
> Because
> - Printf-ing the code is kind of heavy and error-prone,
> - parsing the computed values is some work to handle correctly,
> - the compiler can't tell me if I did something wrong so I get all
> the errors at execution time.
This need not be the case if you apply language embedding/meta-
programmation techniques (see for example [1]). You can even mask R
computations behind plain caml functional types.
I have an unpolished toy example that does this to program arithmetic
functions on regular ocaml types but that use scsh to actually compute
the result (no camlp4 or unsafe features required), I can forward it
to you if you are interested.
Here's an example of a polymorphic cube function, when you invoke
cubei or cubef the result will actually be computed by scsh. The
drawback is that you need to "write" the type your functions by hand
(cf argi argf reti retf).
open Mini
open Override
open Program
let cube_s = fun x -> x * x * x
let cubei_p = compile (argi (reti cube_s))
let cubef_p = compile (argf (retf cube_s))
let cubei : int -> int = as_fun cubei_p
let cubef : float -> float = as_fun cubef_p
However as Ashish pointed out the biggest problem are the data sets,
but it may be that you can keep them in R only with suitable types to
represent them in ocaml.
Best,
Daniel
[1]
article{967844,
author = {Conal Elliott and Sigbj\&\#248;rn Finne and Oege De Moor},
title = {Compiling embedded languages},
journal = {J. Funct. Program.},
volume = {13},
number = {3},
year = {2003},
issn = {0956-7968},
pages = {455--481},
doi = {http://dx.doi.org/10.1017/S0956796802004574},
publisher = {Cambridge University Press},
address = {New York, NY, USA},
}
prev parent reply other threads:[~2008-03-16 21:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-14 11:32 Maxence Guesdon
2008-03-15 12:40 ` [Caml-list] " Ashish Agarwal
2008-03-15 16:08 ` Francois Rouaix
2008-03-15 19:53 ` Ashish Agarwal
2008-03-16 19:01 ` Maxence Guesdon
2008-03-16 21:24 ` Bünzli Daniel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9CECF824-9C61-48A9-809C-D2B152F0EBD3@erratique.ch \
--to=daniel.buenzli@erratique.ch \
--cc=caml-list@inria.fr \
--cc=maxence.guesdon@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox