Lambda the Ultimate

Reminds me of Ian Piumarta's new TR, Open, extensible composition models (slides).

Simple functional languages like LISP are useful for explor-
ing novel semantics and composition mechanisms. That use-
fulness can be limited by the assumptions built into the
evaluator about the structure of data and the meaning of
expressions. These assumptions create difficulties when a
program introduces a composition mechanism that differs
substantially from the built-in mechanism of function ap-
plication. We explore how an evaluator can be constructed
to eliminate most built-in assumptions about meaning, and
show how new composition mechanisms can be introduced
easily and seamlessly into the language it evaluates.

To extend syntax and semantics, it's easier using "eval" messages than to try to use the type system.

I cited Piumarta's Maru in my opening paragraph. It would be interesting to experiment with an actor-based evaluator that takes a Maru-like strategy. If I understand it correctly, Maru associates "evaluators" and "applicators" with the type of the object in the operator position of a combination. This relationship is captured by:

eval(x; e) = apply(evaluators[type(x)]; cons(x; nil); e)
apply(f; a; e) = apply(applicators[type(f)]; cons(f; a); e)

Evaluators are equivalent to my "#eval" messages, which are interpreted in a type-specific way by the behavior of the receiving object/actor. Applicators are equivalent to my "#comb" messages, with type-specific behavior for interpreting combinations.

Why not just use "eval" messages as follows:

Eval(x, e) ~~ x.eval(e)

f "(" a ")" ~~ eval(e) --> f.eval(e)(a.eval(e))

This seems to be a natural consequence of converting from representing operations in functional form to representing operations in object-oriented form, as I discussed here.

If I read your implementation correctly, it is essentially the same algorithm I started with in this article, where I cited your ActorScript as inspiration. That version implicitly uses eager evaluation (requiring special-forms for operatives) and strictly lexical scope (motivating a variety of mutable environment implementations).

The more recent Kernel-inspired evaluator is distinguished by building on the explict-evaluation strategy of Vau, and uses a single consistent implementation of environments with controlled mutability. The message-based evaluation, with explicit customers, also implicitly handles tail-calls appropriately, and introduces concurrency in both operand evaluation and parameter matching.

Integrating functional and imperative programming using message passing is subtle. ActorScript attempts the integration along with logic programming (based on Direct Logic) as well!

In ActorScript, types play an important role in affording binary interfaces so that program defined symbols never have to be looked up at run-time, which is slow and error prone.

I'm looking forward to seeing an implementation of ActorScript that I can play with. I'd love to try out some of your examples.

We're working on it :-)