SMOP: Revision 142
^ Simple Meta Object Programming / Simple Matter Of Programming
If you want to help SMOP, you can just take on one of the lowlevel S1P implementations and write it. If you have any questions ask ruoso or pmurias at #perl6 @ irc.freenode.org.
The Slides for the talk "Perl 6 is just a SMOP"<http://people.debian.org/%7Eruoso/SMOP.pdf>""<http://people.debian.org/%7Eruoso/SMOP.pdf> are available, it introduces a bit of the reasoning behind SMOP. A "newer version"<http://www.yourcargo.org/SMOP.pdf> of the talk presented at YAPC::EU 2008 is available
SMOP is an alternative implementation of a C engine to run Perl 6. It is focused in getting the most pragmatic approach possible, but still focusing in being able to support all Perl 6 features. Its core resembles Perl 5 in some ways, and it differs from "Parrot"<http://www.perlfoundation.org/parrot> in many ways, including the fact that SMOP is *not a Virtual Machine*. SMOP is simply a runtime engine that happens to have a *interpreter run loop*.
The main difference between SMOP and Parrot (besides the not-being-a-vm thing), is that SMOP is from bottom-up an implementation of the Perl 6 OO features, in a way that SMOP should be able to do a full bootstrap of the Perl 6 type system. Parrot on the other hand have a much more static low-level implementation (the PMC)
The same way PGE is a project on top of Parrot, SMOP will need a grammar engine for itself.
SMOP is the implementation that is stressing the meta object protocol more than any other implementation, and so far that has been a very fruitful exercise, with Larry making many clarifications on the object system thanks to SMOP.
* [SMOP Hacking]
* [SMOP Debugging]
* [SMOP Portability]
* [SMOP Status]
^^ Important topics on SMOP
* SMOP doesn't recurse in the C stack, and it doesn't actually define a mandatory paradigm (stack-based or register-based). SMOP has a [Polymorphic Eval], that allows you to switch from one interpreter loop to another using Continuation Passing Style. See [SMOP Stackless].
* SMOP doesn't define a object system in its own. The only thing it defines is the concept of [SMOP Responder Interface], which then encapsulates whatever object system. This feature is fundamental to implement the [SMOP Native Types].
* SMOP is intended to bootstrap itself from the low-level to the high-level. This is achieved by the fact that *everything in SMOP is an Object*. This way, even the low-level objects can be exposed to the high level runtime. See [SMOP OO Bootstrap].
* SMOP won't implement a parser in its own, it will use STD or whatever parser gets ported to its runtime first.
* In order to enable the bootstrap, the runtime have a set of [SMOP Constant Identifiers] that are available for the sub-language compilers to use.
* There are some special [SMOP Values Not Subject to Garbage Collection].
* A new interpreter implementation [SMOP Mold] replaced SLIME
* The "official" smop Perl 6 compiler is mildew - it lives in v6/mildew
* Currently there exists an old Elf backend which targets SMOP - it lives in misc/elfish/elfX
^^^ Other matters
* [SMOP Autovivification].
* [SMOP Boot Sequence].
* [SMOP REFERENCE and RELEASE Policy].
* [SMOP Inter Continuation Communication].
* [SMOP Interpreter Implementation API].
* [SMOP Run Loop].
* [SMOP p6opaque Implementation]
* [SMOP OO API]
* [SMOP Specific Macros]
* [SMOP Default Metaclass]
* [SMOP Lexical Scope Implementation]
* [SMOP Code Implementation]
* [SMOP Late Context Propagation]
* [SMOPP5] - SMOP P5 integration
[SMOP GSoC 2009]
See the [Old SMOP Changelog]