COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems?
Should Combined-Object-Lambda-Archtecture 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 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?
I took the object->lambda approach in TORT (http://github.com/kstephens/tort) tried to keep the OO kernel small, and delay the compiler until after the lisp evaluator. The object system started out “tiny” but to support the lisp evaluator created in an OO-style (which the REPL and compiler is built on) required a lot of basic foundational object functionality. Despite its name, TORT is no longer tiny; I probably didn’t restrain myself enough; it tries too much to support C extension and dynamic linking.
Did Gregor Kiczales, Ian and others stumble upon the benefits of lisp->object bootstrapping .vs. object->lisp bootstrapping? I’ve written object-oriented LISPs before (http://github.com/kstephens/ll based on ideas from OAKLISP). Do OO techniques make language implementation “feel” easier in the beginning, only to complect later on?
Just some ideas, Kurt Stephens http://kurtstephens.com/node/154 _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
