Daniel Ruoso

After a long time imagining when this day would come, today Paweł Murias has created a github fork of the perl interpreter so we can start working on the integration of SMOP and perl5.

Some of you might have heard me saying that the major reason for SMOP to exist today is the prospective integration with the perl5 interpreter so we can use Perl 6 at the same time as still being able to use all of CPAN, including the things that depend on XS, like the fantastic Gtk2-Perl suite.

In fact, I've been blocking pmurias on some things like replacing the refcounting by a trace gc in SMOP exactly because that would make SMOP incompatible with perl5, and I really want them to cooperate.

This integration should happen at the deepest level of perlguts, where the perl5 interpreter should play the role of the SMOP interpreter and every SV* is also a SMOP__Object*.

Paweł has added smop/base.h to the p5 repo and I started adding the SMOP__ResponderInterface* member to some p5 values (right now _SV_HEAD, which defines the first members of every SV value, and the PerlInterpreter). This is the first step that will allow SMOP to use P5 objects without the need for a proxy value.

After talking with nothingmuch on #p5p, I decided to note here the first set of goals of the SMOPP5 integration:

• Making every perl value a SMOP__Object*
• Implemeting Responder Interfaces for each of this values
• Implementing the SMOP interpreter and continuation class APIs in the perl5 interpreter (using Coro::State for now)
• Have SMOP objects visible in perl5 using proxy objects as already happens today

This set gives use the SMOP->P5 integration, after that we're going to need the P5->SMOP integration, which should involve hacking in every p5 macro in the core, which is a *lot* of hacking, so I'll not include it as our goals for now, for sanity sake!

Module loading in Perl 6 is considerably different than in Perl 5. The biggest difference is that in Perl 5, you're always in the main namespace and that is global, which means that it doesn't matter what gets some module loaded, if it ends up in main, you'll be able to find it. Like:

# in some random file loaded indirectly...
*{'main::Foo::Bar::new'} = sub {
  return bless {}, 'Foo::Bar';
}
# in your source file
my $a = Foo::Bar->new();

In Perl 6 that is not the case, when you ask for Foo::Bar, it will do a lexical lookup for the package Foo, which means that it won't immediatly look for it in the global namespace. Although all files start parsing in the GLOBAL package, and by default a class is our, which means that

use v6;
# in some random file loaded indirectly
class Foo::Bar {
  ...
}
# in your source file
my $a = GLOBAL::Foo::bar.new(); # this will work
my $b = Foo::Bar.new(); # this won't

That means that, unlike Perl 5 require, module loading in Perl 6 is not just about loading a file, but it also needs to install a symbol in your lexical scope pointing to the loaded module. And to do that Perl 6 has four control statements: “need”, “use”, “require” and “defines”.

• “need” simply loads something at compile-time without doing any import;

• “require” is the run-time version of “need”;

• “defines” explicitly tells to import some module's exports;

• “use” is a shortcut to “need X defines *”

But that goes a bit beyond that. Consider the following source file, named Sense.pm:

class Sense {
  ...
}
class Nonsense {
  ...
}

When that module is loaded, the two classes are loaded into the comp_unit scope and aliased in the GLOBAL package (as they are “our”). When you

need Sense;

It will load Sense.pm, but it also need to have a local symbol for the “Sense” name, so somehow the implementation of “need” will, at some point, have access to the comp_unit scope of Sense.pm, in order to find a symbol named “Sense”, and alias it back to the current scope. The practical implication to that is that “Nonsense” is not available as a local symbol, but it also tells us a lot about how the loading process work. Basically:

The module loading requires the code causing the load to have access to the recently-loaded-module's outermost lexical scope!

So, it seems that module loading will require one to cache the relationship between the filename and the outermost lexical scope, so the compilation is re-used when some other code “need”s this module. There are some other subtle issues about module loading that I'm going to adress in other posts, but that's it for now.