|
Continuing our in-depth exploration of Perl 6 implementations we interviewed Stefan O'Rear about the Niecza project, the Perl 6 implementation for the .NET and Mono platform.
NV: For starters, what does Niecza mean? Where does the word's come from?
SO'R: It is butchered Czech for a lack of time. The origins are documented at gist.github.com
NV: So why Perl for .NET? What is the idea and motivation behind it?
SO'R: I wanted to try my own implementation of Perl 6; I asked around for a good implementation language with the features I wanted, and Matthew Wilson (diakopter) suggested C#. I had never touched .NET prior to this point
NV: How is C# related to the project?
SO'R: Niecza is mostly implemented in C# and Perl 6.
NV: very interesting. Which parts are C# and which Perl 6, and how do they interact?
SO'R: The parser and translator parts are Perl 6, but the runtime support is in C#.
NV: So the Perl 6 source is parsed by a Perl 6 parser and then translated to IL by C#?
SO'R: Yes. The last part of the translation is done in C#, but most of it is in the Perl 6. The generated IL is mostly function calls.
NV: What are the intermediate steps and representations before we get to the IL bytecode?
SO'R: The grammar's action methods produce a tree of Op objects, which match source constructions; the Op objects are then converted into CgOp objects, which are fairly close to IL; the CgOp objects are encoded in JSON and shipped off to the C# code, which does the final conversion to IL
NV: So there is a Perl 6 AST node transformation going on?
SO'R: The Op to CgOp transformation is in Perl 6, if that is what you mean.
NV: Why target the CLR and not the DLR which is specifically targeted for Dynamic languages?
SO'R: One reason is that nobody told me about the DLR until it was too late. Also, I think the DLR is a bad fit for Perl 6 conceptually and would require a lot of slow glue. In particular, the DLR has a very different idea than Perl 6 about how arithmetic operator overloading should work.
NV:Does Niecza plug into out of the box facilities of .NET like the GC, threading etc?
SO'R: Yes, it uses .NET GC and threading.
NV: So generally speaking that is the big plus of VM's, plugging in into ready made facilities?
SO'R: Yes.
NV: Is language interop with the rest of the .NET languages possible?
SO'R: There is interop support, but it's not transparent;it tries to be as transparent as it can, but when bridging two systems as different as Perl 6 and C#, there will be roughness.
NV: Like mapping Perl 6 to C#/.Net types and vice versa?
SO'R: Yes.
NV: How do you do metaprogramming/introspection - through Reflection?
SO'R: Since Perl 6 classes are not represented as CLR classes, Perl 6 native metaprogramming/introspection does not use CLR Reflection.
NV: Do Rakudo and Niecza start in common ground and then branch off, like being two branches of the same tree ? can they both follow the Perl 6 specs to the letter while at the same time targeting two different VM's?
SO'R: Both implementations follow the spec to the letter, except when buggy. The language isn't adapted to the VM; it would certainly be faster and easier, but we don't want to create branches.
NV: Is low level unmanaged access using P/Invoke or inherent Perl 6 facilities?
SO'R: P/Invoke is not yet available, but it is a high priority.
The inherent Perl 6 facilities (NativeCall aka Zavolaj) will implemented on top of P/Invoke
NV: Ultimately what can one do with Niecza? Is it possible to access .NET libraries or use Linq? Or through Silverlight can you achieve Perl on the browser?
SO'R: You can definitely access .NET libraries, there are a couple of Gtk# samples. Language Integrated Query is a C# feature, and Niecza does not make it available in Perl 6. Silverlight can probably be made to work with some effort; as far as I know it has not been attempted. But Perl in the browser is already a reality thanks to Flavio Glock's "Perlito" system.
|
