"Yet, by (someday) providing all the (supported) APIs, Joker enables higher-level, Clojure-like, APIs (that call these low-level API wrappers) to be written without requiring changes to the Joker codebase or executable itself."
I’ll try to address what I think might be unclear: normally, to make Go APIs available from Joker code, one might write a custom Joker source file, such as std/os.joke, perhaps accompanied by a std/os_native.go file, and then rebuild Joker. Alternately, one could add a namespace to core/data/some-namespace.joke and have it call new Go code, calling the desired APIs, provided in core/procs.go (or similar), which can be more complicated due to needing to modify other files…and then rebuild Joker.
Either way, the source code of Joker has to be modified, and Joker rebuilt, so the API can be called. gostd is intended to provide out-of-the-box access to all the Go standard-library packages via very low-level Joker access.
That allows one to write custom Joker libraries (namespaces) as “pure” Joker code. These would provide Joker-like (Clojure-like) APIs that are implemented by calling the gostd-provided wrappers underneath. No rebuild of Joker would be required, nor the source tree changed (in the source-control sense; it is actually changed to build the gostd version). What this does not solve, out of the box, is access to APIs outside the Go standard library. Select “popular” libraries might be added to the canonical version; but it’s likely I’ll add a mechanism to easily configure what additional libraries (packages, wrapped by Joker namespaces) are desired for a particular build of Joker, which (of course) would require rebuilding Joker, though not to contain substantial new Joker code just to provide decent, Clojure-like, access to those APIs.
Going forward, I’m considering changing gostd so all those “low-level” APIs are made private (and thus largely undocumented by default, though the generate-docs.joke tool does now have an option to generate docs for private as well as public members of each namespace!).
In conjunction with that, I hope to provide some useful automatic generation of Clojure-like wrappers, using various heuristics.
That might (in at least some cases) eliminate the need to hand-write one’s own Joker libraries to wrap the gostd-generated ones more elegantly. I hope this explanation helps!
One step I forgot to mention is that the “pure” Joker code one might write, to provide Clojure-like access to raw Go APIs wrapped by gostd, would presumably be deployed alongside one’s application as yet another namespace, or perhaps more widely if used across an organization or in a project.
That is, such Joker code would be organized and deployed as described in https://github.com/candid82/joker/blob/master/LIBRARIES.md, intended for developers of Joker code, rather than requiring the kind of in-depth knowledge described, for Joker developers, in https://github.com/candid82/joker/blob/master/DEVELOPER.md.
@iku000888 yes. this Joker fork has some of it, but its not true interop. have you tried anything in this direction? happy to chat in the clojurians slack about it or if you email me to ben@enet.io