Being able to use Perl modules is fairly unlikely, because most languages are not like Perl. You will likely be able to use (80% of) Perl modules with Kurila, a Perl fork. Perl6 (if it ever comes out) is supposed to have a Perl5 interpreter mode, but as far as I know, currenly only the Perl5 interpreted version of Perl6 is able to run Perl5 code (no surprise).

You can embed a Perl interpreter into any language that can embed C subroutines - see perlembed for how to do this. You will need a C compiler though, to compile Perl for that.

You can use other languages from Perl, by using the Inline family of modules. Most of these modules require a compiler for the other language.

There are some ways of using parts written in other languages that are specific to different operating systems. On Windows, you can transparently use any object that has an OLE interface through Win32::OLE. To write an OLE object in Perl, you have to buy the ActiveState PerlKit (I believe), but that works on Windows only. For OSX (and I believe MacOS as well), there are AppleScript events that you can issue from Perl. I'm not sure if the CamelBones library supports receiving such events as well.

The most generic ways of interfacing two programs is to either run the other code as a subprogram (see perlipc) or have one program be a webserver and use the other one to make requests to it.

Perl 6 (if it ever comes out)...

See Rakudo, running on Parrot. The February release will include a perl6 binary with object support. (See Parrot 0.5.2 can make perl6.)

• Using a socket: both languages run in their own process space and some kind of RPC is used to call one into the other through the socket. You have to serialize the data crossing the interface and deserialize at the other side while remaping it to the other language types. Using something standard as XML or YAML for the serialization is an option, but it has a big overhead.
• Using XS (or Inline, SWIG, etc.): both languages run in the same process and the data is converted between the two languages using some C code. You have to provide a set of functions on every side of the interface to call the other language (for instance, on the language calling perl: perl_call_sub, perl_call_method, perl_eval). That solution is usually much faster, but you have to program it in C/XS.

If you tell us what is your target language, we would be able to give more specific indications about how it can be done.

Thank you all for the fantastic replies. I thought Inline was a very interesting bit of Perl. I also appreciate the pointers towards perl4caml and CamelBones.

The question came out so vague because I was simply curious about the issue of how various languages played nice with one another. Solutions that I already knew about include setting up XML-RPC, SOAP, or some other interface that's interoperable between languages. I know almost nothing about XS, but I think that's the solution I was more interested in.

I originally thought of the question when I was going through some particularly nasty legacy perl code. I thought the code was perfect for a basic CRUD webapp in Rails. However, since there were many other legacy systems that depended on the legacy code, I wanted to make a Ruby interface to the legacy code, and use that Ruby interface in the webapp. Wrapping around the legacy code would allow me to design away all the years of hacks and be able to test it at the same time.

You can use Perl modules in OCaml programs with perl4caml.

CPAN has a separate category for Language interface that suggests some ways of interfacing with other languages. There are also different inter-operability approaches ranging from Web-Services to language-specific Parsers. For specific types of interfacing/languages, there's always Google.

If you are into ObjectiveC, and perl, it's a lot of fun..

The other one that comes to mind, that I hadn't already seen here may be too obvious to mention, but it's very useful:
backticks. You can pass arguments via shell and files pretty intuitively.

-d

Regards, Peter