wallet/docs/libraries/scripting.md

---
title: Scripting
...

Initially we intend to implement human to human secret messaging, with
money that can be transferred in the message, and the capability to make
messages public and provably linked with an identity

But obviously we are eventually going to need bot responses, and bot
scripts that can interact with the recipient within a sandbox. Not wanting
to repeat the mistakes of the internet, we will want the same bot language
generating responses, and interacting with the recipient.

There is a [list](https://github.com/dbohdan/embedded-scripting-languages) of embeddable scripting languages.

Lua and python are readily embeddable, but [the language shootout](https://benchmarksgame-team.pages.debian.net/benchmarksgame/) tells us
they are terribly slow.

Lua, however, has `LuaJIT`, which is about ten times faster than `Lua`, which
makes it only about four or five times slower than JavaScript under
`node.js`.   It is highly portable, though I get the feeling that porting it to
windows is going to be a pain, but then it is never going to be expected to
call the windows file and gui operations.

Lisp is sort of embeddable, startlingly fast, and is enormously capable, but
it is huge, and not all that portable.

ES (JavaScript) is impressively fast in its node.js implementation, which does
not necessarily imply the embeddable versions are fast.

Very few of the scripting languages make promises about sandbox
capability, and I know there is enormous grief over sandboxing JavaScript.
It can be done, but it is a big project.

Angelscript *does* make promises about sandbox capability, but I have
absolutely no information its capability and performance.

Tcl is event loop oriented.

But hell, I have an event loop. I want my events to put data in memory,
then launch a script for the event, the script does something with the data,
generates some new data, fires some events that will make use of the data, and
finishes.

Given that I want programs to be short and quickly terminate, maybe we
do not need dynamic memory management and garbage collection.

Lua is slowed by dynamic memory management.  But with event
orientation, dynamic memory management is complete waste, since your
only memory management is allocating continuation objects to be fired on
the next event - which is to say, all memory management is explicit, when
an event handler detaches.