Parrot Virtual Machine/HLL Interoperation

HLL Interoperability

Parrot was designed not just for Perl6, even though that was one of the bigger driving forces initially. Parrot is being designed and implemented to be a virtual machine for all dynamic programming languages (and even a few statically-typed ones too). The ultimate goal is to be able to combine tools and libraries written in various languages together, and allow developers to write different parts of a project in the language that makes the most sense to that project.

Parrot makes interoperability easy, but it's ultimately the responsibility of the language designers to make sure that their languages play nicely with others.

Sharing Data

Vtables: Standard Interfaces

All PMC objects implement the standard vtable functions, and these are to be the primary interface for dealing with foreign or exotic data types. If you receive a Ratio object from common LISP, you might not know what it's methods are, or what it's internal storage structure is when you use it from Perl 6. However, by calling the standard vtable methods, you can interact with it in an easy way.

Sharing Functions

Multi Methods

Like many modern programming languages, Parrot allows function name overloading. Called multiple method dispatch (MMD), Parrot's function call system is very powerful and flexible. In the MMD system, multiple functions in a single namespace can have the same name, so long as they have different call signatures. A call signature specifies the number and type of parameters and return values that the function expects. If we call a function:

(a, b, c, d) = Foo(x, y, z)

Parrot only calls a function Foo if it has three inputs and four outputs. Multiple dispatch isn't just used for functions, it's also used for opcodes. A program (or, more likely an HLL) can add new opcodes with the same name as an existing opcode, so long as it uses a different function signature. This allows a very powerful and flexible way to customize your system.

We will talk more about MMD in a later chapter.

Translation Interfaces

The idea of including some sort of translation interface, functions that would automatically convert calls from one HLL to appropriate calls to another, has been attractive to some developers. However, there is a large associated development cost because for n languages we would require $n^{2}$ interfaces to translate to and from them all. Because of this additional complexity cost, it is not recommended to handle data or function sharing using interfaces.

Documentation

The most important thing a language developer can do is document their interfaces. It is important to document what data types a function expects and what data types it returns. This way, a person using these libraries from a different languages know how to interact with these functions and objects.

Plus, documentation may expose some functions or objects as being overly difficult for reuse. This will help deter developers from using a complicated interface. It will also help to expose to the library designers ways to simplify their library.