[Goober5000]

[Nuke]

couldn't you just call a script-eval with tostring(x)?

im really not even sure how to get a sexp to return a value or if you can stick that value into a variable, but this line of script would read a num variable and store it to a string variable:
mn.SEXPVariables[stringvarname] = tostring(mn.SEXPVariables[numvarname])

im not sure that would fit in the limited space of a script-eval

[Zacam]

Number 2 would be my long-term preference as well, but using LISP instead of Lua.  The entire sexp language is basically LISP anyway.  (That's why they're called "s-exps" in the first place.)  It would take considerably less work than a sexp-to-lua compiler, because not only do you not have to translate the language, you wouldn't even have to re-implement any of the APIs.

But our current scripting is via LUA, right? So wouldn't it make it more accessible to scripting if there was a working SEXP-to-LUA vs. a re-write to LISP, or am I missing something?

[Goober5000]

There already is a working SEXP-to-LUA interface; it's called eval-sexp.  You can bridge between one system and the other.

What I'm talking about is a re-implementation of the current system.  The entire sexp language is LISP, with some FS-specific extensions.  If we changed the code to use a real actual factual LISP interpreter instead of our ad hoc, informally-specified, bug-ridden, slow implementation, the sexp system would suddenly become an order of magnitude more powerful, while retaining exactly the same syntax and complete reverse-compatible functionality.

[Dragon]

That sounds really interesting.