andreasronge

Very interesting. This has some overlap with my lisp + runtime approach and sema-lang.

See https://sema-lang.com/ (which I just found today) and https://ptc-runner.dev/blog/tools-built-for-llms/

But I love your focus on local development using smaller models.

I’ve been working on an open source MCP server that gives AI agents (or coding assistants) a stateful, sandboxed REPL using a small Clojure-like language.

The main idea is that an agent should be able to explore MCP tools more like a developer explores an API from a REPL, instead of having every schema, tool response, and intermediate result pushed into the model context.

Example (done over multiple REPL sessions):

  (mcp/servers)
  (dir 'github)
  (doc 'github/search_issues)
  (apropos "calendar")

  (let [r (tool/mcp-call {:server "fs"
                          :tool "read_text_file"
                         :args {:path "/tmp/sandbox/notes.md"}})]
      (if (:ok r)
        (count (split-lines (:value r)))
        (fail (:message r))))

The reason I built a small custom Clojure-like language instead of using Python/JS is so I can fit the needs of the LLM: easy to sandbox, give good feedback to LLM as well as operational (handle many concurrent low latency stateful connections)

https://github.com/andreasronge/ptc_runner/blob/main/mcp_ser...

Interesting, I'm not familiar with that paper, but I guess the performance gain comes from raising the abstraction level (hiding solver boilerplate). PTC-Lisp could achieve the same thing by defining constraint-building functions as tools, and the LLM writes high-level PTC-Lisp that calls a solver. In fact, Lisp has a natural advantage here: instead of building a separate DSL with its own compiler (as I guess Logic.py did), Lisp can extend itself with macros — code is data, data is code - however this is not impl. yet in ptc-lisp.