Okay @borkdude #sci is amazing. I can't believe this thing runs in advanced compile in cljs. Wow. Well done.
In a browser environment, if I am trying to run cljs code that references compiled javascript (such as npm/module split code/React), I would include the exported javascript functions as per normal, right?
Also I tried #sci in #sci in #sci last night and it actually works 🤣 amazing
I think we can invent @borkdude Arithmetic now where 0 = (#sci x) , 1 = (#sci (#sci x)), 2 = (#sci (#sci (#sci x))), etc
Also, is there anyway to serialize/deserialize the state of a running #sci interpreter? 🤔
I’m not sure if you’ve looked at Unison as an example of serializable program state, but it may be worth reading about. Language was designed with that in mind: https://unison-lang.org I think this is probably one problem where static types help a lot; serializing dynamic state seems harder because you don't have a compiler to give you as many guarantees.
@afoltzm is it a JS runtime language...?
Nope, it's implemented in Haskell
Ok. Need something javascript compatible but always like reading up on new languages, thanks for pointing it out!
Oh I didn't mean to imply it was a readymade alternative, more as potentially informative prior art for the idea of serializable program state / closures in general terms, should you end up taking on that problem in #sci
Serializable closures 😬 that sounds like a lot of work, good point
@goomba How you reference compiled JS is either via the global JS environment, or via what you provide via the SCI ctx, either through :classes or via :load-fn
Brilliant
About serializing: there have been some efforts, but the problem is a circular reference to the context and how to serialize closures. You might be able to get it to work, but I haven't really pursued it