LightMachine

Mutable what?

I added a file, `examples.js`, which shows how you can encode some array algorithms on λJSON. It may look extremely inexpressible due to so lack of loops, math, etc - but it is still able to encode any conceivable algorithm, although more carefully.

Ah, fair enough. The user should avoid using native JS constructs on the code to be stringified, though - it is an interesting/useful side effect of the method that you are able to, but ideally you would define your functions using only the pure λ-calculus grammar.

Thanks for figuring that out!

There are many possibilities since you can pass any program/algorithm through LJSON while still having a good level of safety. You could it, for example, to allow your users to pick an AI strategy for their bots in a game, among billion of other things. But there are many restrictions, so you can't just write arbitrary JS functions. You have to design them much more carefully by requesting the proper primitives, using the technique I explained with the hypothenuse example. Of cours, you could just request `window` as a primitive and get everything, but yea...

Very good catch. Any suggestion how I could improve the usage of null for determining the end of a call list?

There is no protection against non-termination. For example, an user could give you this function:

    f = (function (x){ return x(x); })

Now, if you call `f(function(f){return function(x){ return f(f(x)) }})`, it'll not halt. But there are good principled ways to work around that, such as adding a type system like System F. That would discard 100% of the programs that halt, at the cost of also losing some programs that do halt.

Done.

The point of ADT syntax is to allow deriving many functions on different data structures automatically. For example, lists and some functions can be defined as:

    cons      = (x list cons nil -> (cons x (list cons nil)))
    nil       = (cons nil -> (id nil))
    map       = (f list cons -> (list (comp cons f)))
    head      = (list -> (list (a b -> a) nil))
    tail      = (list cons nil -> (list (h t g -> (g h (t cons))) (const nil) (h t -> t)))
    zip_with  = (f a b -> ((left a) (right f b)))
        left  = (foldr (x xs cont -> (cont x xs)) (const []))
        right = (f -> (foldr (y ys x cont -> (cons (f x y) (cont ys))) (const (const []))))
    length    = (flip comp const)

The very same definitions could be written more tersely as just:

    List     = #{Cons Type * | Nil}
    cons     = (Ctor 0 List)
    nil      = (Ctor 1 List)
    head     = (Getter 0 0 List)
    tail     = (Getter 0 1 List)
    zip_with = (ZipWith List)
    length   = (Size List)

Where Ctor/Getter/ZipWith/Size are proper derivers. It is possible because all the information you need is there, but it is very hard to come up with those derivers and I currently only have some very bloated derivers for Scott encoded structures, and none for Church encoded structures yet.