So you think Inline C is pretty cool, but what you really need is for Perl to work with the brand new programming language "Foo". Well you're in luck. Inline.pm has support for adding your own Inline Language Support Module (ILSM), like Inline::Foo.

Inline has always been intended to work with lots of different programming languages. Many of the details can be shared between implementations, so that Inline::Java has a similar interface to Inline::ASM. All of the common code is in Inline.pm.

Language specific modules like Inline::Python are subclasses of Inline.pm. They can inherit as much of the common behaviour as they want, and provide specific behaviour of their own. This usually comes in the form of Configuration Options and language specific compilation.

The Inline C support is probably the best boilerplate to copy from. Since version 0.30 all C support was isolated into the module Inline::C and the parsing grammar is further broken out into Inline::C::grammar. All of these components come with the Inline distribution.

This POD gives you all the details you need for implementing an ILSM. For further assistance, contact inline@perl.org See "SEE ALSO" below.

We'll examine the joke language Inline::Foo which is distributed with Inline. It actually is a full functioning ILSM. I use it in Inline's test harness to test base Inline functionality. It is very short, and can help you get your head wrapped around the Inline API.

Except for load(), the subroutines in this code are mandatory for an ILSM. What they do is described below. A few things to note:

Inline::Foo must be a subclass of Inline. This is accomplished with:

@Inline::Foo::ISA = qw(Inline);

The line 'require Inline;' is not necessary. But it is there to remind you not to say 'use Inline;'. This will not work.

Remember, it is not valid for a user to say:

use Inline::Foo;

Inline.pm will detect such usage for you in its import method, which is automatically inherited since Inline::Foo is a subclass.

In the build function, you normally need to parse your source code. Inline::C uses Parse::RecDescent to do this. Inline::Foo simply uses eval. (After we strip out all occurances of 'foo-').

An alternative parsing method that works well for many ILSMs (like Java and Python) is to use the language's compiler itself to parse for you. This works as long as the compiler can be made to give back parse information.

This section is a more formal specification of what functionality you'll need to provide to implement an ILSM.

When Inline determines that some Foo code needs to be compiled it will automatically load your ILSM module. It will then call various subroutines which you need to supply. We'll call these subroutines "callbacks".

This subroutine receives no arguments. It returns a reference to a hash of ILSM meta-data. Inline calls this routine only when it is trying to detect new ILSM-s that have been installed on a given system. Here is an example of the has ref you would return for Foo:

This is a reference to an array of language name aliases. The proper name of a language can only contain word characters. [A-Za-z0-9_] An alias can contain any characters except whitespace and quotes. This is useful for names like 'C++' and 'C#'.

This routine gets passed all configuration options that were not already handled by the base Inline module. The options are passed as key/value pairs. It is up to you to validate each option and store its value in the Inline object (which is also passed in). If a particular option is invalid, you should croak with an appropriate error message.

This subroutine is responsible for doing the parsing and compilation of the Foo source code. The Inline object is passed as the only argument. All pertinent information will be stored in this object. build() is required to create a cache object of a specific name, or to croak with an appropriate error message.

This is the meat of your ILSM. Since it will most likely be quite complicated, it is probably best that you study an existing ILSM like Inline::C.

Inline.pm creates a hash based Perl object for each section of Inlined source code it receives. This object contains lots of information about the code, the environment, and the configuration options used.

This object is a hash that is broken into several subhashes. The only two subhashes that an ILSM should use at all are $o->{API} and $o->{ILSM}. The first one contains all of the information that Inline has gather for you in order for you to create/load a cached object of your design. The second one is a repository where your ILSM can freely store data that it might need later on.

Inline.pm has been set up so that anyone can write their own language support modules. It further allows anyone to write a different implementation of an existing Inline language, like C for instance. You can distribute that module on the CPAN.

If you have plans to implement and distribute an Inline module, I would ask that you please work with the Inline community. We can be reached at the Inline mailing list: inline@perl.org (Send mail to inline-subscribe@perl.org to subscribe). Here you should find the advice and assistance needed to make your module a success.

The Inline community will decide if your implementation of COBOL will be distributed as the official Inline::COBOL or should use an alternate namespace. In matters of dispute, I (Brian Ingerson) retain final authority. (and I hope not to need use of it :-) Actually modules@perl.org retains the final authority.

But even if you want to work alone, you are free and welcome to write and distribute Inline language support modules on CPAN. You'll just need to distribute them under a different package name.