Gregory's Server@neauoire so, with Co, I work towards this by removing the boundaries of "applications" completely; everything is just a routine, and they're all floating in memory. an "application" just becomes an entry point routine that points to the other routines that make up its logic and "vectors", and all of those associated routines can be called by anything that knows its address, which can be stored in a content-hash-to-address map (as in Co) or a string-name-to-address map for someone to call direct
|
5 comments
 @neauoire some of the other components of the language, specifically its use of content-hashes to refer to subroutines, create the environment for this to work. there's also a notion of a single "symbol library" where all of your compiled routines live, and which can be accessed both at writing/compile time and runtime (right now managed by the VM environment, but ultimately hoping to have it live in the VM as a bootstrapping "OS")  @jakintosh Oh! of course XD *slaps forehead* the definitions are accessible through the symbols! So you're planning on making it possible to do remote API calls between Co environments right? @neauoire should be possible, but one of the main goals is to be a local-first-first computing environment (😅), in that instead of asking other environments to execute code, you can always just grab a symbol and execute it yourself. so the equivalent of a public API would be more like an annotated list of symbol links, { "sqrt32f", "a1b2c3", "calculate sqrt of 32b float on top of the stack" }, and you ingest the 'sqrt32f->a1b2c3' link to your local name table and fetch the hash from the network |
@jakintosh Can I see what you expose via the API? I'm wondering how to communicate the expected arity through the API? I don't have a real usecase for this atm, so it's more of a solution in need of a problem, so do you have a scenario that I could try to replicate, like, how do you ( plan to ) make use of this in practice in your workflow?