JohnEarnest
commented
9 years ago oK is written with all the IO verbs factored out of the main interpreter, permitting applications which embed it to customize their behavior easily. I encourage you to do some tinkering in your own fork- the oK browser frontend and the CLI repl each serve as examples. You are essentially plugging additional methods into the verb dispatch table here- be aware that you will have to register verbs for all the atom/list combinations you wish to handle and potentially wrap your routine in ad()/am()/ar() to get the desired atomicity (fully atomic dyad, right atomic monad, right atomic dyad, respectively).
In order to really benefit from using K I think JS interop routines will need to be fairly high-level and capable of operating on large chunks of data at once. A wrapper for the JS eval() function from a K string should not often be necessary, but I imagine you would need something along those lines occasionally as an "escape hatch".
The file convert.js contains routines for marshalling data between ordinary JS types and the types used by the K interpreter. If convert was extended to wrap verb trains and functions in a JS "thunk" which converted JS arguments to K arguments, invoked oK, and then converted the result back to JS datatypes it would be possible to register K functions as callbacks for any desired browser behavior. Note that there are other impedance mismatches between the JS and K type systems- for example, JS has no notion of a "symbol", JS dictionaries are always keyed by strings, and K uses 0 and 1 to represent boolean values while JS has a dedicated type. The most information-preserving and convenient conversions are not obvious and will depend on expected usage.
I'd be happy to provide further clarifications as necessary.
Going back to JS from Q is painful. I'd like to play around with K for client-side stuff. ok seems to be the best bet. Has any thought been in to how ok could interact with the parent JS interpreter?
JS-as-a-handle (i.e., 9:) seems to make the most sense to me as a first step. Strings would work, though a more intricate expression-as-a-tree "IPC" format would be more useful for more complex tasks.