SMOP Grant Final Report
Thu, 19-Feb-2009 by
Alberto Simões
edit post
<![CDATA[
<ul><li><b>Project:</b> Simple Meta Object Programming</li><li><b>Grantee:</b> Daniel Ruoso</li><li><b>Grant Manager</b>: Jeff Horwitz</li><li><b>Started:</b> August, 2008</li><li><b>Finished:</b> February, 2009<br /></li></ul>Follows the conclusion report, by Daniel Ruoso.<br />
Ok, I'll try to summarize what happened in the last 7 months (wow, it's been a long time). Leading us to understand where SMOP is today.<br /><br />When the grant started, SMOP was pretty much a conceptual experiment, leading to reviews of S12. I only had some small examples of Object-Oriented features and was only having a few glances on a higher-level language. The code was basically C with some code using the sm0p macro language (now deprecated).<br /><br />What is stable since then is the definition of the SMOP__Object and SMOP__ResponderIterface. It seems to survive every concept-check done so far, and not few people did it, specially the people from Moose had take a deep look on that concepts and tried to find corner cases, but fortunally the model is simple enough so it survived all this peer reviews. Which was a very important thing, IMHO.<br /><br />On top of that, the "Polymorphic Eval" concept not only survived to equally challenging conceptual reviews, but also prove itself as the most important feature of SMOP. At first, it allowed SMOP moving out from SLIME (the Smop Lame Interpreter IMplEmentation) to Mold, which is a register-based simplistic interpreter (it knows only 4 ops) that is pretty much stable. Additionally, this feature took us to some very interesting conclusions about future integration with perl5.<br /><br />There came the idea on how to integrate perl5 and SMOP, which was already reviewed by some #p5p people, and looks very promising. I use to say that if everything goes fine, perl 5.12 will run Perl 6. This got pmurias into a very interesting adventure, which was to integrate p5 with SMOP directly using Coro::State (this was suggested by mst). And we have some exciting progress, including a successfull use of "use SDL :from<perl5>", with values coming back and forth from SMOP to p5, thanks to the SMOP__ResponderIterface.<br /><br />We also have an integration with libpcl, which allows the use of C continuations together with the SMOP runloop. That basically means that you can make a callback to SMOP from C code, yield from the C code and wait for SMOP to get back to it without stacking in the C runtime. This is a crucial feature to allow integration with different interpreters.<br /><br />The area where SMOP is a bit weak at this point is memory management, the choice for a refcounting gc has its price. There are several memory leaks in SMOP that are very hard to hunt down, as every leak in a refcounting gc. On the other hand, the choice for refcounting is also a very important aspect on the prospective integration between p5 and smop.<br /><br />Enough with the core, let's see another point of the grant: The built-in types. Initially, there were very few built-in types. We basically the types that we needed to actually run some code, like bool, Capture, Interpreter. We had a significant development there, with several objects that are available for the higher-level language, like Array, Hash and Code. We also have p6opaque now, which is the base for the high-level objects.<br /><br />We're actually in a point where it's not worth writing any other types in C. The amount of abstractions already demands us to write the built-in types in Perl 6, and there is still a significant progress in that area. Some sketches can be seen in smop/src-s1p, and some code that already compiles for the built-in types (Multi.pm is the first) is available in mildew/prelude.<br /><br />Additionally, SMOP already supports Control Exceptions and Failures, where the SMOP implementation of the return control exception is the first to actually implement the semantics as spec. In order to do that, SMOP also supports call with current continuation in the standard Code object, which is how the code inside CATCH or CONTROL exits to the outer-outer block when it exits.<br /><br />For bootstrapping pourposes, we have the AdhocSignature object, which implements ACCEPTS and BIND by calling custom ad-hoc code defined by the compiler, while we also have the DefaultBlockSignature that implements the topic variable as spec.<br /><br />There are still some open spec issues, the most important being the Capture behavior. SMOP already implements one part of a DWIM code, but it still needs spec on how much DWIM a capture should perform. The development of SMOP also raised the need for the "\" modifier in the signature, which "capturize" that argument instead of forcing the context defined by the sigil.<br /><br />To the last item of the grant: the parsing. Mildew is today a pretty nice STD backend (which is pretty much leaded by pmurias). It works by getting the VAST tree, returned by STD, and running some tree transformations to turn it into a Mildew AST, which then can be compiled to mold code. Unlike other implementations, mildew advances not in number of features, but in number of concepts implemented, since it's a backend for STD, it doesn't take shortcuts to support some features, so most regular P6 code won't run in mildew, but a very impressive set of examples in mildew/t, mildew/example and mildew/prelude shows what kind of code it can compile and that SMOP can run successfully.<br /><br />All that being said, and taking a look at the grant proposal, I think we took a diverse path in the way of this grant. But I don't think it was a bad idea at all, we might not have all built-in types implemented in a first-stage language, but we have a STD compiler instead of mini-language and we're looking forward to do the actual typesystem bootstrap, which, IMHO, is something better.<br /><br />That way, I think it wouldn't be unreasonable to consider this grant completed, considering that not only the actual effort was pretty much bigger than the one initially proposed, but the deliverables we have are pretty much more valuable as well.<br /><br />daniel<br /><br />
]]>
Comments (1)
Daniel, good detailed report! thanks!
