Perl 6
SMOP: Revision 173
^ Simple Meta Object Programming / Simple Matter Of Programming
is a C based interpreter (runloop) that executes, what different compiler (like [Mildew] ) produce.
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]
* [SMOP Capture Expansion]
* [SMOP sm0p Language]
* [SMOP Prelude Lexical Scope]
* [SMOP Multi Sub Dispatch]
* [SMOPP5] - SMOP P5 integration
^ Roadmap
[SMOP GSoC 2009]
See the [Old SMOP Changelog]
is a C based interpreter (runloop) that executes, what different compiler (like [Mildew] ) produce.
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]
* [SMOP Capture Expansion]
* [SMOP sm0p Language]
* [SMOP Prelude Lexical Scope]
* [SMOP Multi Sub Dispatch]
* [SMOPP5] - SMOP P5 integration
^ Roadmap
[SMOP GSoC 2009]
See the [Old SMOP Changelog]
