Hi Kurt, Lisp is more expressive than lambda alone since Lisp contains forms that cannot be represented by lambda directly - an encoding must be used. A novel explanation of this math phenomena can be found in Barry Jay's recent book, Pattern Calculus, published via Springer-Verlag. But very briefly, pattern matching is more general than beta reduction used in the lambda calculus.
I hope this pointer will help you work through your intuition, but the hard work is on you since reading Barry's book has some pre-reqs. ;) Barry does read this list here and there, fyi. Sent from my Droid Charge on Verizon 4GLTE ------Original Message------ From: Kurt Stephens <[email protected]> To: "Fundamentals of New Computing" <[email protected]> Date: Saturday, February 11, 2012 7:23:01 PM GMT-0600 Subject: [fonc] COLAs or CLOAs? : are lambda systems fundamentally simpler than object systems? 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 _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
