neontology

Maybe it’s just because I wrote it, but I really think that Nu’s architecture is quite transparent: S-expressions are parsed into self-evaluating objects, all of which are implemented with classes expressed in the Objective-C runtime.

Every object has an eval: method that triggers its own evaluation in a passed-in context, and contexts are represented by NSDictionaries of key-value pairs. Context keys are symbols, symbols are “interned” strings stored in a symbol table, and each symbol also has a slot for a globally-assignable value.

One of the most important new elements of Nu is the NuCell class, an Objective-C version of the classical Lisp cons cell. There’s the first strike against Nu: making cells Objective-C objects wastes a word per cell (for the isa pointer), but to me, the simplicity of that was well worth the storage cost. All Nu code is parsed into structures built out of cells, and since cells and symbols both support archiving, the “compiled” code can be written to a file or sent over a network connection.

Objects of most preexisting ObjC classes just evaluate to themselves, but NuCells (a.k.a. lists) respond in a special way.

A list that begins with an operator or block sends that operator or block an “eval” method with the rest of the list as arguments. Here’s a simple example:

(+ 2 2)

+ is a NuSymbol that is bound to a singleton operator object that implements addition. The two numbers are NSNumbers, and everything is linked together with NuCells.

Lists that begin with other types of objects use the rest of the list to construct a message that is sent to the object at the head. Here’s how you might use that to create a Cocoa window:

((NSWindow alloc)
      initWithContentRect:'(30 200 800 800)
      styleMask:(+ NSTitledWindowMask 
                   NSClosableWindowMask 
                   NSMiniaturizableWindowMask 
                   NSResizableWindowMask)
      backing:NSBackingStoreBuffered
      defer:NO)

Operators and blocks are objects, and occasionally we want to send messages to them. Since the normal calling convention doesn’t allow that (lists that begin with an operator or block are treated as operator calls), there’s a special operator that you can use to explicitly send messages to objects. Assuming that block is bound to a block, (send block arguments) is the Nu equivalent of [block arguments]; in Objective-C.

In both operator calls and message sends, the evaluation context is sent with the evaluation message so that arguments can be evaluated in the caller’s context. Arguments to methods are always evaluated, but operators may or may not evaluate all of their arguments, and sometimes operators evaluate their arguments multiple times. For blocks, there are a couple of interesting cases.

A block is represented by a list of argument names, an execution context (saved when the block is created), and the parsed code to be evaluated. The do operator can be used to explicitly create blocks; several other operators create blocks implicitly.

When a block is created with the function operator or called anonymously, all of its arguments are evaluated in the calling context before the block is evaluated.

When a block is added as a method, it is wrapped in a libffi closure that automatically adds self and super to the block’s context each time it is evaluated. Method arguments are always evaluated in the calling context before the method block is evaluated.

Most of the time, the evaluation of code in a block takes place in the context that was saved when the block was created. But when a block is created with the macro operator, no context is kept. Instead, when the macro is evaluated, all block evaluation takes place in the caller’s context. To access the macro’s arguments, a special symbol margs is pushed into that context (and if there’s an existing value, that’s saved until the macro finishes). The margs symbol is just the list of unevaluated arguments to the macro; the macro itself determines when and how they are evaluated. Next, any names in the block that begin with a double underscore are replaced with generated symbols, and then the block is evaluated. Here’s a simple example:

(macro factorial    
     (set __x (eval (car margs)))
     (if (== __x 0) 
         (then 1)
         (else (* (factorial (- __x 1)) __x)))) 

In practice, you’d never compute factorials like this, but it illustrates an important problem that can occur with macros. Since macros are evaluated in the caller’s context, each recursive evaluation of factorial potentially sets our double-underscored x to a new value. That would be bad, so each time we evaluate this macro in Nu, the double-underscored x is replaced with a new automatically-generated name that is guaranteed to be unique.

Wow, describing this is more work than I expected. Let’s take a break. Send me some feedback and I’ll clean this up, and maybe our next topic will be Nu’s interaction with the Objective-C runtime.