Rebuild LISP system for function encoding

[robin-swift]

See the contents of assets/designs/.

The idea is that by using LISP for user submitted functions we can have a much simpler data sanitation process.

Note that we're not supporting general LISP expressions (we may need to find out what this subset would be called) and they are loaded as YAML because they are only one input, one output functions as strings.

[petrsorfa]

Would you consider embedding Python as well? That's something I could do.

[robin-swift]

As far as I can understand there's a licensing issue with that. Python is GNU GPL and Embroidermodder 2 is zlib.

LISP expressions for custom user designs was a way of encoding functions that I can hand code an interpreter for.

The other problem is data validation. I want to be able to track the source of errors so not embedding a scripting language will cut down on the sources of errors.

[robin-swift]

Thanks for your interest though, if you're willing to help in general I could really do with more hands on deck.

What else would you find interesting?

Cheers,

Robin

[petrsorfa]

Actually, Python is now PSFL which is compatible with GPL. ZLIB is also compatible with GPL, so they can be used together.

Other interests for me are UI. I've done some SDL, OPENGL, etc.. work. Also done some commercial and GCC compiler expression work

LISP, as great as it is, is definitely not a well known language, and will deter other folks from writing scripts. Python is the popular choice (although personally I'd prefer a C, C# or C++ interpreter)

[robin-swift]

ZLIB is also compatible with GPL

While that's true, it means that if you compile GPL code into a zlib project, the resulting software is under a viral license, like GPL. This is something I don't want to change because it's foundational to the project.

although personally I'd prefer a C, C# or C++ interpreter

So I chose LISP expressions to aid parsing. The code to support Polish notation is a lot lighter, especially with the way that the lists are always explicit as opposed to the very implicit way a C expression has to be parsed. There is no operator precedence to deal with.

The C family requires that we either import a big library (unless you can find a lightweight one) or build a very complex parser (along the lines of half of the Dragon Book). This solution is under a few hundred lines (https://www.buildyourownlisp.com/ I'm not doing anything like this complicated and this is 1000 lines).

I've done some SDL, OPENGL, etc.

Now that's what I want to hear! See my new issue Embroidermodder/Embroidermodder#282 to see where we're at with that. Any help, particularly PRs would do a lot for the project.

[petrsorfa]

You are absolutely right, C# and C++ interpreters are heavyweight.

The other language to consider is LUA, but honestly it's not a big deal what the solution is, as any programming language is ok.

(Dragon book => shudder)

I'll pick up the conversation in https://github.com/Embroidermodder/Embroidermodder/issues/282

[robin-swift]

I consider this a low-level support issue, so I'm transferring it to libembroidery.

[robin-swift]

libembroidery may not actually use any lisp features directly, but since EM2 needs some method of user input for functions the interpreter will be part of this code.

[tatarize]

Pyembroidery for python already exists. It's basically libembroidery re-written for python along with some needed re-encoding technologies to ensure compatibility between different formats.

[petrsorfa]

Pyembroidery

Nice! Thanks for the pointer. Although Robin is implementing is a scripting language within the frontend, which is a bit different.

[robin-swift]

This is resolved by TinyScheme see https://github.com/Embroidermodder/TinyScheme