- Name: Daniel Ruoso
- Title: SMOP - Simple Meta Object Programming
- Synopsis: SMOP is an alternative C implementation of a runtime to run Perl 6. It is built with a pragmatic approach, while still focusing in implementing all the features Perl 6 needs. SMOP resembles perl 5 structure, and implement the concepts of "Responder Interface" and "Polymorphic Eval" that should enable a considerable set of extensibility. More information can be found at: http://www.perlfoundation.org/perl6/index.cgi?smop
SMOP - Simple Meta Object Programming
SMOP is an alternative C implementation of a runtime to run Perl 6. It is built with a pragmatic approach, while still focusing in implementing all the features Perl 6 needs. SMOP resembles perl 5 structure, and implement the concepts of "Responder Interface" and "Polymorphic Eval" that should enable a considerable set of extensibility. More information can be found at: http://www.perlfoundation.org/perl6/index.cgi?smop
Benefits to the Perl Community:
While Parrot is the most solid solution to deploy Perl 6 in the long term, on the other hand, the challenges Parrot has accepted had proven to consume more time and resources than previously expected. The efforts around the Pugs project and the sub-projects that arised from that had shown that diverse Perl 6 development generate a more value than actually divide the community, as some have concerned at the time
SMOP is, in the same sense as Pugs, an implementation that tries to bring Perl 6 to life with a more pragmatic vision, but unlike the runtime developed in the "v6-alpha", "MiniPerl6" or "KindaPerl6" projects, it aims to support all the Perl 6 features from bottom-up, bootstrapping its object system so it should be possible to bootstrap the compiler. SMOP is also, targetted as a prospective backend of KP6, in a way that all the work invested in the KP6 grammar engine will be immediatly inherited by SMOP in the moment KP6 is compiled to SMOP.
SMOP has already a planned ROADMAP, in which it is very clear where its effort starts to intersect with KP6. The aim of this grant proposal is to take SMOP to the point where it can be effectivelly used as a KP6 backend, as it's marked in point "0.4.4" of the ROADMAP.
The focalized effort can be seen as three different phases, that are marked by the level of completeness of the runtime and by the sub-languages used in the process.
- Stage 1 SMOP -- s1p: This language, still translatable to C, should be used to implement the builtin types in a Perl 6 sub-language. At this time all native types are declared, and p6opaque is implemented
- The Builtin types: This includes all the Perl 6 built in types, as described in the synopsis.
- Perl 6 SMOP: The AST types and the KP6 backend.
My expectations are, with the funding, to be able to expend 15 hours per week in SMOP development and regain its rythm. Considering that, in terms of schedule, I expect:
* Stage 1 SMOP -- s1p: 4 weeks.
* The Builtin Types: 5 weeks.
* Perl 6 SMOP: 4 weeks.
I have been following the Perl 6 development for some time already, having worked in the p6-on-p5 bootstrap efforts since March 2006, having worked closely with Flavio Glock in that time as well as in the recent KindaPerl6 developments. I was able to bootstrap KP6 once, but the performance issues made me research on alternatives. During YAPC::EU::2007, I've been in conversations with the Parrot team, but at the end I couldn't find an easy way to take a pragmatic approach using Parrot codebase, in a way that I then started YAP6, which was recently renamed to SMOP.
In order to be able to expend 15 hours per week in a three months period in SMOP development, I would need the financial support of 2,500 USD. This value could be delivered in a per-month basis, subject to the submission of a report of the development.