IronLisp, MOP and more
Scott's last post had a link to a new opensource Lisp project for the DLR, called IronLisp (in homeage to IronRuby and IronPython). I've been a fan of Lisp for a number of years and I'll keep my eye on IronLisp to see how it goes. If your interesting in running Lisp on the CLR then should also check out fellow brit Rob Blackwell's L# and Common Larency too. If your interested in trying out Lisp then you should really download a Lisp compiler, Common Lisp (CL) is an ANSI standard (X3.226-1994) and will contain all the language features and object system. The CLR\DNL compilers will still be short of features so to get a true grasp of the language i'd start with a native compiler.
Lisp has several object systems, the CL object system is called the Common Lisp Object System (CLOS). CLOS is often built around a Meta Object Protocol (MOP). CLOS is prehaps one of the most powerful object systems I have come across and when I heard about Rubys object system is reminded me a lot of CLOS. I've been watching the Parrot project develop and ran into a post on OnRuby about the OO requirements that Cardinal (Ruby compiler for Parrot) places on Parrot and the adoption of a Simple-MOS to faciltate this. CLOS on Parrot wuth this addition would be in theory possible. It seem's that others are also looking at this approach, Attila Szegedi, a developer on the Rhino Javascript project has also explored this concept.
It struck me thinking that if Ruby and Lisp have similar requirements in how there object models work then a MOP makes a lot of sense and what about the DLR. I've mailed John with my thoughts and have since run into a post of Jim's about the OO support in the DLR.
For types that are defined by a dynamic language, we provide a more dynamic way to respond these messages. These dynamic types will implement a special interface - IDynamicObject - that can provide customized handling for all dynamic operations. One of the key steps in implementing a dynamic language on the DLR is to implement this interface for the standard object type used by a given language. This means that the IronPython implementation implements this interface on Python-defined classes to support the correct dynamic behavior following Python's rules for multiple inheritance and method resolution order. Similarly, the DLR-based JavaScript implementation implements this interface on JavaScript functions/objects in order to implement the correct prototype-based inheritance for that language. Each language doesn't need to know anything about the details of the type system in the other languages, but just needs to know what messages to pass to those objects and counts on the other languages correctly implementing their side of the contract.
One very obvious thing missing from the current DLR is a standard default implementation of this interface. This would be useful to people who wanted to implement simple scripting languages on the DLR who weren't trying to precisely match the semantics of an existing language. This would also be useful for libraries that wanted to create a generic expando object to pass to consumers. I expect that we'll provide this in the future, but at the moment our attention remains focused on the cases where we need to capture the exact semantics of existing dynamic languages where the interface approach provides the needed flexibility.
Atilla has a comment that suggests this breaks away fron a MOP approach
instead of providing interfaces on objects (and thus internalizing the knowledge required for cross-language interop into object implementations), it is a more flexible approach to define interfaces for metaobject protocols, have each language ship its implementation of it (I call these metaobject protocol implementations "object navigators" or just "navigators"), and allow languages to use other languages' metaobject protocol implementations to access and manipulate those languages' native objects, in addition to using its own MOP implementation.
I look foward to hearing Johns thoughts on this.