It's much easier to work with LISP. It's functional, trees are easy to reason about. We're using an even more simplified language in this work. It's kind of like the MNIST for progsynth research. Scaling this to real and useful programming languages and domains is still non-trivial, and is a major drawback of our work here.

Thanks for your response. I think I would even rather it be a limited subset of Python. But I seem to be in the minority here. Cool work!

S-expressions are basically an AST with minimal parsing. It’s very convenient to work with.

Yeah, that's basically my objection. The convenience seems to hide something important. I know you can write any program with LISP, but using LISP for this kind of thing seems to be a symptom of limited applicability.

I don't share this concern. You can easily write Python, Typescript and C++ in S-expression format since you're basically writing an AST, that's the whole point. Conversion between one and the other is... maybe not trivial, but certainly not rocket science.

E.g. https://hylang.org/

Not to mention, there are languages with the same expressiveness as most Lisp-like languages. Dylan and Julia immediately come to mind. Julia in particular makes it easy to convert between code and syntax tree data, so you have arguably the same capabilities as Lisp macros, in a syntax that would appease GP's preferences.

I think another big thing that makes Lisp-like languages (Common Lisp, Clojure, Racket, ...) convenient for this kind of work is the fact that everything is an expression. Having "statements" and "expressions" separate makes writing some programs awkward. I use Clojure at my day job, and the way I write code takes for granted that I can simply bind `foo` to the result of a `case` or an `if` without ad-hoc operators that have completely different syntax from their statement-equivalents.

Conversion between s-expression and C, Java, Python syntax is trivial.

Programming language syntax is just for humans and not relevant. Writing correct programs is all about semantics.

The model is written in Python. The intermediate language is an S-expression, its just an easy representation of a tree. An alternative could be JSON.