A study on scripting language APIs
“Applications written in two programming languages, in order to optimize parts where performance is critical or to obtain extensibility through user-written scripts, are common-place nowadays. There are several ways to obtain this kind of interoperability; ideally, however, a language should provide a foreign language interface (FLI), allowing programmers to send and receive both data and function calls to code written in another language. This work discusses the main issues involving the design of APIs for integration of language environments within C applications. We present the main problems faced in the interaction between code executed in an environment with inherently dynamic characteristics such as a scripting language and C code. We compare approaches employed by five languages when handling communication between the data spaces of C and embedded runtime environments and the consequences of these approaches in memory management, as well as sharing of code between the C application and that from the scripting language. We illustrate the diferences of the APIs of those languages and their impact in the resulting code of a C application through a case study. Diferent scripting languages were embedded as plugins for a library, which on its turn exposes to client applications a generic scripting API. This way, the code of each plugin allows us to observe in a clear and isolated way the procedures adopted by each language for function calls, registration of C functions and conversion of data between the environments.”
. In this post, I will outline some of the most important reasons we chose to go with Perl, and hopefully clarify some of the misconceptions surrounding Perl and the Perl community.
