Replacing builtin macro languages with perl -- how difficult?

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Replacing builtin macro languages with perl -- how difficult? by Loops (Curate) on Nov 23, 2014 at 05:39 UTC
It really depends on the structure of the existing software. But I don't think it'd be a trivial undertaking in even the best of cases. However, it isn't hard to setup a little environment and play with embedding Perl. Check out perlembed.	[reply]
Re^2: Replacing builtin macro languages with perl -- how difficult? by Anonymous Monk on Nov 23, 2014 at 21:15 UTC
Thanks, but this is actually worse than piping to and from a perl process. It looks perlembed passes everything via command line arguments wrapped in a C function call. The Java program I'm working with has a macro language that probably calls Java library routines to do various things. I want Perl to do the same thing as well as seeing the underlying data if I want to take advantage of a perl library. There doesn't seem to be a way for perl to discover or act on the Java program's data. Hacking together interpreters across languages is something I haven't done. Sorry if I wasn't clear on this.	[reply]
Re^3: Replacing builtin macro languages with perl -- how difficult? by Loops (Curate) on Nov 23, 2014 at 21:32 UTC
The examples in that page are toys, but show the way to do what you want. Consider again Calling Perl from C. You don't have to restart Perl every time as in the example, just leave it there and call into it any number of times passing in data to operate on as you like. But maybe you're not really thinking of having Perl available inline and callable like that. If you just want to access Java from your Perl code, take a look at Inline::Java where you can write bridge code in Java that make whatever you want available to your Perl modules.	[reply]
Re: Replacing builtin macro languages with perl -- how difficult? by RonW (Parson) on Nov 24, 2014 at 17:18 UTC
As an example of a (very) non-trivial embedded Perl integration, the CodeWright IDE (now long discontinued) has embedded Perl as one of its extension languages. It works very well. Embedding Perl is only slightly more work than creating an XS module. Most of the effort is "repackaging" the data being transferred between Perl and the "other language". If you want to embed Perl, first learn how to make XS modules. Beyond learning about moving data between Perl and C (or other language), you might need to allow the called Perl routines to call routines provided by the host application.	[reply]
Re: Replacing builtin macro languages with perl -- how difficult? by Anonymous Monk on Nov 24, 2014 at 11:57 UTC
You would have to have the source-code of the big software package in question ... and a helluva lot of time and energy ... to build a new macro processor into it. Only if the application is "otherwise externally controllable" could a different language e.g. Perl be used to control it. For example, if a Windows package fully supported OLE.	[reply]
Re^2: Replacing builtin macro languages with perl -- how difficult? by Corion (Patriarch) on Nov 24, 2014 at 12:05 UTC
As Java has reflection (which basically can be construed as OLE), there is a possibility to create a Java-Perl bridge where Perl code can issue calls to Java. See for example Inline::Java. This is still a huge lot of work and replacing one macro language interpreter with another one is not easy.	[reply]