<d_bot>
<cemerick> I have a very crude (synchronous, stateless) node invocation module, but something like the above would be a huge improvement. Reminds me of Foil http://foil.sourceforge.net/
<d_bot>
<cemerick> I've been taking on more and more JS dependencies, so something similar is necessary
<d_bot>
<rgrinberg> You aren't using jsoo, right?
<d_bot>
<cemerick> I might use jsoo for the node-side eval server bit
<d_bot>
<rgrinberg> Sounds reasonable
<d_bot>
<cemerick> not going to mess with any ppx to start, though what inline-js does with TH is pretty
<d_bot>
<rgrinberg> Why do you need ppx?
<d_bot>
<cemerick> @rgrinberg not a need, but being able to "interpolate" OCaml values into JS snippets to be evaluated would be great; see the `$hostname` example here https://www.tweag.io/blog/2019-05-09-inline-js/
mro has joined #ocaml
<d_bot>
<rgrinberg> I see. Tbh, I think ppx is more of a headache than its worth for something as simple as templating
wonko has quit [Remote host closed the connection]
<d_bot>
<cemerick> yeah, it'll remain a TODO until I feel compelled by real usage
<d_bot>
<rgrinberg> if you're using jsoo on node side, you could save yourself a bunch of time with converters by marshalling
<d_bot>
<cemerick> @rgrinberg not sure what you mean?
<d_bot>
<rgrinberg> Well, when you evaluate the js, how do you plan to pass the returned value to OCaml?
<d_bot>
<rgrinberg> Actually, I suppose everything is going to `Json.t`
<d_bot>
<cemerick> inline-js has its own binary protocol; I'll probably just be using JSON to start
<d_bot>
<cemerick> plus a "reference" option
<d_bot>
<rgrinberg> Okay. With marshal, you can serialize any value in jsoo and then pass it to native OCaml. Of course you'll get segfaults if the types don't agree
<d_bot>
<cemerick> oh, the snippets being evaluated are def untyped, so that's off the table
<d_bot>
<rgrinberg> Do the snippets need to be in JS though? Can't they be in OCaml?
<d_bot>
<rgrinberg> I suppose linking the entire compiler and jsoo compiler into your binary is out of question 🙂
<d_bot>
<cemerick> No no, this is def not for pushing delimited sections of OCaml code to node, etc
<d_bot>
<rgrinberg> Yes, I just find it fishy that you need to another programming language. I guess it's necessary if youre JS snippets are completely dynamic
mro has quit [Remote host closed the connection]
<d_bot>
<rgrinberg> but if they aren't and you're limited to a subset of calls, I would just write a jsoo wrapper lib, compile it to js, and run that. Serialization is of course handled by marshalling
<d_bot>
<cemerick> well, my objective is to use off-the-shelf JS libraries that have no OCaml equivalent. The code in the snippets being evaluated should be quite terse; implicating jsoo at that level feels quite extravagant
<d_bot>
<rgrinberg> I guess it's a matter of taste. To me, jsoo is the goto for JS integration.
<d_bot>
<rgrinberg> I'll sketch out what I have in mind a little more:
<d_bot>
<rgrinberg> 1. Create a module interface containing all the functions to foreign js libs you might make.
<d_bot>
<rgrinberg> 2. Implement this module interface in jsoo using the ffi + marshalling over stdin/stdout.
<d_bot>
<rgrinberg> 3. Implement the same module interface in native OCaml by running a node process and making calls over stdin/stdout.
<d_bot>
<rgrinberg> Haven't thought about it too much, but that's what seems sane to me.
<d_bot>
<rgrinberg> Anyway, this is just food for thought. I'm not really familiar with your problem
<d_bot>
<cemerick> it's certainly a more formal approach
<d_bot>
<cemerick> feels like a lot of work though; typical workflow I'm aiming for is (a) add js library to my local package.json, (b) (often) copy/paste the necessary JS into where I'll be calling out to that library from OCaml, (c) sanitize the return value(s) to ground them in my canonical types
<d_bot>
<cemerick> coming up with module interfaces for random JS libraries can be very un-fun
<d_bot>
<cemerick> anyway, we'll see how it all shakes out in short order here
cemerick has left #ocaml [#ocaml]
<d_bot>
<cemerick> actually, that ts2ocaml project might help a lot there
<d_bot>
<rgrinberg> You can always start with this module interface `val call : name:string -> args:Json.t list -> Json.t` 🙂
<d_bot>
<rgrinberg> Yeah, for step (c).
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
infinity0 has quit [Remote host closed the connection]
infinity0 has joined #ocaml
<d_bot>
<Chris Armstrong> AWS have been working on a related tool that acts a way for arbitrary languages to call JS code via marshalling - it's very primitive though because it's only one way (x language => JS) and does not garbage collect the stuff it marshalls. They used for AWS-CDK to create bindings for other languages