Lizzie, a Turing Complete “Structure Query Language” for your server

Although Lizzie is only in its first initial 0.5 release, and not mature by any measure, I must confess that I have a lot of ideas in regards to it. First things first though, Lizzie will highly likely never grow particularly much in size. This is because of its extendible architecture, that allows you to extend it as you wish. Sure, I’ll fix bugs in it, and I might add one or two additional features, but Lizzie is not one of those programming languages that’ll simply pack features upon features until it’s all fat and muddy.

Not because I don’t want to add features to it, but because it’s not necessary to add features to it, since if I miss some feature, I can simply create a delegate and add to my “binder”, or create a method on the type I bind to it, and such easily extend the language, without modifying it. Below is an example.

using System;
using lizzie;

class MainClass
    // This method will be available as a function in your Lizzie code
    [Bind(Name = "write")]
    object Write(Binder<MainClass> ctx, Arguments arguments)
        return null;

    public static void Main(string[] args)
        // Some inline Lizzie code
        var code = @"
var(@foo, 57)
set(@foo, +(foo, 10))

        // Creating a tokenizer for our Lizzie code
        var tokenizer = new Tokenizer(new LizzieTokenizer());

        // Creating a lambda function from our code, using the above tokenizer
        var function = Compiler.Compile<MainClass>(tokenizer, code);

        // Creating an instance of our class, which we can bind to our Lizzie code
        var context = new MainClass();

        // Creating a binder, and adding some pre-defined functions to it
        var binder = new Binder<MainClass>();
        binder["var"] = Functions<MainClass>.Var;
        binder["set"] = Functions<MainClass>.Set;
        binder["+"] = Functions<MainClass>.Add;

        // Evaluates our Lizzie code, making sure we bind it to our instance
        function(context, binder);

        // Waiting for user input

Notice how the “write” function is not something that actually exists in Lizzie, but available to my Lizzie code, since the type I am binding my code towards have that method, and have marked it with the “Bind” attribute. This adds a new “keyword” to my Lizzie code, that I can use internally within my Lizzie code, to invoke C# methods, having access to the “context” that my Lizzie code is evaluated within.

With the ability to easily extend a programming language such as I illustrated above, the need to expand on the language simply isn’t there. So Lizzy will probably never grow much in size beyond its current codebase, which is surprisingly small, ~2 KLOC in fact. In such a way, you might argue that C# becomes the equivalent for Lizzie as Macros are to Lisp.

The above extension abilities though, opens up a really interesting axiom I think myself – Which is the ability to create generic functions such as I do above, that solves generic problems, such as (securely) querying your database for instance. This allows for me to create a handful of methods, where I can use Lizzie as the “query language”, deciding what I want to evaluate on my server, and have that code translated to SQL, according to what authorisations the client has to do some particular operation on some particular table. This again allows me to for instance create a single HTTP REST endpoint, that accepts Lizzie code as input, and returns JSON to the caller – Which of course allows me to create a web app, where the server side doesn’t contain a single line of business logic code, and my JavaScript client transmits Lizzie code to the server, which effectively *is* my business logic. And in fact, I am confident in that I’ll be able to pull it off securely, such that having a client inject malicious code that is to be evaluated on my server, becomes literally impossible. This just so happens to tie in perfectly well with “fat client frameworks”, such as Angular and React, where the assumption is that you’re supposed to build your entire application on the client, and simply use the server as an HTTP REST endpoint. The only difference is that instead of POSTing JSON, and having JSON returned, you POST Lizzie code, yet still get JSON in return.

Then the job of authorising whether or not a specific client is legally allowed to perform some specific operation or not, becomes a simple configuration job on the server, allowing me to “declare” which tables and operations a specific client is legally allowed to do, according to some role based security map, which decides which server side methods Lizzie code transmitted from that particular client will load up, and allow that particular client to execute – And if a client is not authorised to execute some specific “keyword”; Exceptions! Which allows me to use the same HTTP REST endpoint to retrieve any data from any table in my database on the server side, including aggregated values and joins, without opening up for security holes, effectively turning Lizzie into the equivalent for servers in general, as what SQL is for your database. Creating methods that are not related to databases is also easy may I add, such as creating a method that allows an (authorised) client to send an email, change a configuration setting, etc, etc, etc – Is obviously equally easy, and can be done securely, without opening up a “can of worms” in regards to security …

In such a way, Lizzie might prove to become the “Structured Server Side Query Language” of computing. Simply put, because what man would I be, if I didn’t have a bunch of fancy acronyms, to describe my axioms … πŸ˜‰

SSSQL for the masses πŸ˜€


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.