Embeddable Common Lisp 23.9.9 (opens in new tab)

The SCI/babashka clojure interpreter might be a good fit, if you're ok with a lisp.

It's mature and fully sandboxed.

https://github.com/babashka/nbb

I've wondered the same. There's https://jsonlogic.com/ but that seems like a data interchange format for logic, not something an end user or developer would write themselves.

If Scheme is something you enjoy, BiwaScheme's interpreter can be instantiated from within Javascript and can be used to evaluate Scheme code.

https://www.biwascheme.org/

Lua is usually the embedded language of choice. If you are focused on security, you could check out the Roblox fork, Luau (https://github.com/Roblox/luau) where the creators took extra care to lock down the language on what scripts could do.

Janet is not an implementation of common lisp, so you cannot run lisp code with it. ECL is an implementation of common lisp, so it can run common lisp code.

If you don't care about running common lisp code, you can get up and running in janet more quickly.

In terms of ease of embedding in C code, a comparison of different languages IME would be Lua/Fennel > Janet > Chibi Scheme > Guile Scheme > ECL.

Can you run janet in iOS?

Historically it's been hamstrung by wasm's lack of tail call elimination, but that appears to have been merged: https://v8.dev/blog/wasm-tail-call

That's why the support is "preliminary". I plan to write some compelling examples for the emscripten target. Here is a "raw" build that shows repl (on some browsers results of evaluation show in the javascript console): http://turtleware.eu/static/ecl/ecl.html -- this is a little older build, but following instructions in INSTALL will get you to the same place.

While simple scripts can produce binaries as small as simple C programs, you are forgetting that dynamically loading libraries has its own cost. e.g. a "hello world" on my machine is a 50 kb binary, which sounds awesome, but running otool on the binary shows a different story.

  hello:
    @rpath/libecl.21.2.dylib (compatibility version 21.2.1, current version 0.0.0)
    /opt/local/lib/libgmp.10.dylib (compatibility version 15.0.0, current version 15.1.0)
    /opt/local/lib/libgc.1.dylib (compatibility version 7.0.0, current version 7.2.0)
    /opt/local/lib/libffi.8.dylib (compatibility version 10.0.0, current version 10.2.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

Depending on how many dynamically linked libraries you have to load, this can result in lower runtime performance than simply using e.g. Clozure CL, which has pretty fast startup time (approx. 13 ms on my machine) but much larger binaries since the binary is essentially self-contained and contains a whole CL implementation, runtime, kernel, etc. inside.

Thanks! I think that the number of changes between ECL and MKCL is quite big. ECL had a short break in development between 2013 and 2015, other than that it is an actively developed project.