SMOP: Revision 67
^ Simple Meta Object Programming / Simple Matter Of Programming
If you want to help SMOP, you can just take on of the lowlevel S1P implementations and write it. Any question ask ruoso 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.
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 second most important difference is that SMOP doesn't have any kind of bytecode generation/interpretation. SMOP will probably traverse something that looks a lot more an AST then some assembly language. This also allows easy integration with other runloops.
The same way PGE is a project on top of Parrot, SMOP will need a grammar engine for itself. [KindaPerl6] is one that is designed with portability in mind, so it should be easy to just implement a KP6 backend to emit C code that uses the SMOP runtime to then bootstrap the grammar engine in SMOP itself.
SMOP already uses KP6 to parse the "stage 0" language that is used to build the SMOP execution frames, and it should be also used to compile the "stage 1" language, as soon as SMOP
has some more features in its runtime.
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]
^^ 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 [KindaPerl6] parser or whatever parser gets ported to its runtime first.
* SMOP defines two [Domain Specific] Languages for low-level aid:
** [SMOP sm0p Language]: A small macro language that builds node for the [Default SMOP Interpreter Implementation] in C.
** [SMOP s1p Language]: (read "swamp") A language to help building the high-level built in types, but still translatable to C.
* 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].
^^^ Other matters
* The array and hash autovivification is discussed in [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 Development ROADMAP
In order to keep this simple, the ROADMAP will stay here and will be edited as needed.
^^^ S1P - Read it "Swamp"
* x.x.x - p6opaque.^!methods().push($method)
* x.x.x - p6opaque.^!methods().item(int index)
* 0.2.2 - p6opaque Responder Interface (This is the default Perl 6 OO Responder Interface)
* x.x.x - Low-level Array implementation
* x.x.x - Low-level Hash implementation
* x.x.x - Low-level Code implementation
* 0.2.3 - Low-level Attribute implementation
* 0.2.4 - Low-level Package implementation
* 0.2.5 - Low-level SubMethod implementation
* 0.2.6 - Low-level Signature implementation
* 0.2.7 - Default MetaClass implementation (This is the default Perl 6 OO Meta Class)
* 0.2.8 - s1p compiler
* 0.2.9 - src-s1p/Object.pm compiled to src-s1p/Object.c
* 0.2.10 - Final review on the s1p language
* 0.2.11 - Object.new() working
* 0.3.0 - Object with all features working
^^^ Completing SMOP runtime
* 0.3.1 - SMOP NATIVE prototypes and lowlevel operators
* 0.3.2 - Undef builtin types.
* 0.3.3 - Immutable builtin types.
* 0.3.4 - Mutable builtin types.
* 0.4.0 - Lexical Scope / Namespaces.
^^^ Perl 6 SMOP
* 0.4.1 - AST types.
* 0.4.2 - AST -> Stack runtime transformation (real interpreter)
* 0.4.3 - KP6 backend
* 0.4.4 - KP6 can compile grammars to SMOP
* 0.5.0 - KP6 grammar compiled
* 0.9.0 - KP6 bootstrapped in SMOP
* 1.0.0 - STD ported to SMOP
^^^ Other Features
* x.x.x - perl5 embedded - libperl
* x.x.x - parrot embedded - libparrot
* x.x.x - python embedded (stackless python?)
* x.x.x - jvm embedded - libgcj
* x.x.x - spidermonkey embedded - libmoz-js
^^ SMOP Changelog
Usually, things from ROADMAP should come to here when its done.
^^^^ 2008-07-09 - Daniel Ruoso
* x.x.x - lowlevel method uses the new signature for "call". This is important for the test/14 still in development.
^^^^ 2008-07-08 - Daniel Ruoso
* x.x.x - smop_lowlevel only uses capture-less DESTROYALL call for a few selected types.
^^^^ 2008-07-04 - Daniel Ruoso
* x.x.x - p6opaque successfully delegates the calls to the metaclass (valgrind-clean)
^^^^ 2008-03-11 - Daniel Ruoso
* x.x.x - Low-level Scalar implementation
^^^^ 2008-02-22 - Daniel Ruoso
* 0.2.1 - Low-level Method implementation (this is not the standard Method type, just something that complies to the API)
^^^^ 2008-02-14 - Daniel Ruoso
* x.x.x - Runtime creation of constant identifiers
^^^^ 2008-02-05 - Daniel Ruoso
* *FIRST MAJOR MILESTONE ACHIEVED:* sm0p - Lame Default SMOP Interpreter Implementation
* 0.2.0 - Final review on [SMOP REFERENCE and RELEASE Policy] and code revision for memory leaks.
^^^^ 2008-02-01 - Daniel Ruoso
* 0.1.4 - Final review on Continuation Passing Style implementation
^^^^ 2008-01-31 - Daniel Ruoso
* 0.1.3 - sm0p preprocessor
* x.x.x - Several bug fixes in the capture and in slime.
* x.x.x - 02_stack.t does ok 1..4 for the first time, this means that sm0p is interpreted correctly
^^^^ 2008-01-24 - Daniel Ruoso
* x.x.x - Automake prepared to run the sm0p preprocessor.
* 0.1.2 - SMOP SLIME prototypes and lowlevel operators
* x.x.x - SMOP__SLIME__Capturize
* x.x.x - SMOP__SLIME__Node
* x.x.x - native int type
* x.x.x - SMOP__SLIME__CurrentFrame
^^^^ 2008-01-23 - Daniel Ruoso
* x.x.x - SMOP__SLIME__Frame first code
* x.x.x - native bool type
^^^^ 2008-01-21 - Daniel Ruoso
* 0.1.1 - Capture type (lowlevel implementation)
^^^^ 2008-01-18 - Daniel Ruoso
* 0.1.0 - Port YAP6__CORE__Value code to SMOP__Object code.
* 0.x.x.x - "Identifier Name Constant" type and the definition of the pool of constants.
See also the [Old YAP6 Changelog].