Kurt Stephens

Should Combined-Object-Lambda-Architecture really be Combined-Lambda-Object-Architecture?

Ian Piumarta’s IDST bootstraps a object-system, then a compiler, then a lisp evaluator. Maru bootstraps a lisp evaluator, then crafts an object system, then a compiler. Maru is much smaller and elegant than IDST.

Are object systems necessarily more complex than lambda evaluators? Or is this just another demonstration of how Lisp code/data unification is more powerful?

If message send and function calls are decomposed into lookup() and apply(), the only difference between basic OO message-passing and function calling is lookup(): the former is late-bound, the latter is early bound (in the link-editor, for example). Is OO lookup() the sole complicating factor? Is a lambda-oriented compiler fundamentally less complex than a OO compiler?

Abstract

I have been interested in optimal low-bit tag schemes on machine words in latently-typed languages. There are different schools of thought on how to handle the trade-offs between Fixnums (integers smaller than word size) and allocated objects.

Ian Piumarta’s libid object library is a very simple prototype-based object system with unresolved method delegation. It is used in the Pepsi/Coke COLA system (available at http://vpri.org/fonc_wiki/index.php/Sources) as the basis for all object representations and meta-behaviors. libid assumes that a reference to an object’s method table, or “vtable” resides at the word before the object’s address.