User:TvojaStara/Language interoperability
 | This user page may require cleanup to meet Wikipedia's quality standards. The specific problem is: Working on it. Please help improve this user page if you can; the talk page may contain suggestions. |
Language interoperability has several possible meanings. It may refer to combining code written in multiple programming languages in a single artifact, like an ELF or .NET Framework assembly. It might also refer to sharing of data structures between applications written in different programming languages or Remote Procedure Calls between such applications.[1]
Techniques
[edit]All techniques for achieving language interoperability can be generally described as finding a common level of abstraction that both languages or technology stacks share and engineering a procedure calling, data interchange format and/or data interchange mechanism on top of it. This common platform or abstraction level might take various forms. In case of source compatibility, the common platform is the subset language compiler and tooling around it. For multilanguage VMs the platform is the virtual machine and the data interchange mechanism is centered around the idea of an object (as in OOP) that all languages can interface with.
Additionally, it is possible to devise extra infrastructure. Operating systems provide means for interprocess communication. There are application level message busses. D Bus Apache Kafka, Rabbit MQ, ...
Source compatibility
[edit]A programming language may be designed to be source compatible with another programming language. This allows treating all programs in the subset language as superset language programs and gradually enhance subset programs with superset language features if it proves desirable.
extern "C" {
}
Name mangling. Parameter type based overloading is disallowed in extern C blocks.
Interoperability from C to C++ is trivial, from C++ to C requires unmangled functions to call as interface.
Source to source compilation
[edit]If languages are not source compatible, it is still possible to devise an automated transformation to turn source code in one language into a valid source code of the other language. Language which has extensive infrastructure around it to be target of this kind of transformations can be considered a glue language. The difficult part is to translate library calls because libraries differ between languages.
Object file compatibility
[edit]Both C compilers and Fortran compilers produce object files. This is object in the general meaning of the world and unrelated to object oriented programming. Since Fortran 2013 the standard specifies and linked together. On UNIX-like operating system, the format of object file is the Executable and Linkable Format. For this to work, Application binary interface. If the languages in question don't share function calling conventions, the files cannot be linked. C and Go.
VM
[edit]API sharing and reuse via virtual machine .NET CLI compliant languages list of JVM languages
Both the .NET Framework and the Java Virtual Machine are language agnostic. JVM and CLI languages commonly have a mechanism for accessing and creating with Java or CLI objects respectively.
A language that runs in a VM can use an object created in different language in the same VM. The VM operates the required abstraction of the object representation that permits to call a method of a class defined in the second language. In this one can reuse the libraries written in another language of the same VM: e.g. a program written in Groovy, Scala or Clojure can use any library written in Java.
The .NET Framework has been designed to be language independent. Accordingly, the virtual machine is called Common Language Runtime. The important organizational unit of code are a class library which contains objects. Classes in a class library and properties of an object can be accessed by code written in any language, regardless of the original language of the class. A part of .Net (Partition I, Clauses 7 through 11 of the ECMA-335 Standard) prescribes a common set of features that all programming languages should support. This set of features is called Common Language Specification. Classes/Objects that expose to callers only those features encompassed by the CLI are guaranteed to be fully usable from any of the .NET languages.[2]
The Java Virtual Machine has been designed with only Java in mind. Still, JVM compliant languages did appear. Those languages were compiled to bytecode originally intened for Java. These languages use the Java objects for interoperability. JVM 7 added a new bytecode invokedynamic [3].
Operating system or communication mechanism
[edit]Interprocess communication
[edit]Most interprocess mechanisms are facilitated by OS, however, there are some Shared filesystems, sockets, that can span multiple operating systems.
files, network sockets, UNIX pipes (available in nonUNIX systems), messaging queue provided by OS, application messaging server (abstraction over some OS based IPC primitive) D-Bus, CORBA, COM, RabbitHQ, Windows Communication Foundation
MPI is not suitable because it is not flexible, it is intended for paralelism, it is not possible to add or remove nodes during computation.
microservices
Microservices is a system building pattern which separates a system into a set of dozens of decuopled interoperating services each usually runing on separate virtual machines and often each having a separate database with clear APIs between them, event bus. The purpose is to disentangle the system, make dependencies between components more explicit. This in turn allows developing each service independently on others. Making changes quickly. Versioning, being able to revert to previous state. XXX points out that
Nick Maclaren Building Applications out of Several Programs http://people.ds.cam.ac.uk/nmm1/MultiApplics/index.html suggested organizational pattern for scientific and technical computing tasks so avoid complicated protocol which might itself become a source of errors, unidirectional data transfer or a stateless challenge response
Other interoperablity techinques
[edit]Source-to-source compilation
[edit]If a VM is a source VM, not a bytecode VM. This simplifies implementation input source code is easier to verify than bytecode. JavaScript, Dart. Typescript, Coffee script, ES6 versions
Foreign function interface
[edit]
Bindings
[edit]Language-independent specification
A binding accesses the code of interest by one of the other means and provides a native language API. It can be automatically generated or handwritten. Handwriting is time consuming and requires binding creators/people skilled in both languages. Automatic generation does not translate coding idioms from one language to other so API users should be familiar with both languages to understand the API better. Documentation has to be revised by hand in either case.
Problems are midigated if the target and source language are similar or the source language is less featurefull than the target language or if the transformed interface uses only a limited easily transpatable subset of the host language features.
Glue languages
[edit]Glue language is a particular mode of use of a programming language which supports one or more interoperability techniques listed above and that makes it suitable for writing glue code.
Haxe, JavaScript
Examples
[edit]Imagine having a library written in Fortran xx for performing numeric integration with delays. Using this library directly only from code in Fortran or a later version 2003, 2008. Since fortran 2003, object files created by Fortran compliers are binary compatible with C object files. It is therefore possible to use the functions from C or C++ and link with the Fortran code directly.
Example
fortran procedure to http://www.math.ntnu.no/preprint/numerics/2008/N7-2008.pdf file: 903.zip ref: TOMS 37,2 (Apr 2010) Article: 23 for: {FRB}--{Fortran} routines for the exact computation of free rigid body motions by: Elena Celledoni and Antonella Zanna size: 3104 kB http://calgo.acm.org/
Various other programming languages have support for C object files, Julia. Therefore, the function can be relatively easilly called from Julia.
One might write a Fortran program which provides an IPC interface for the numeric function of interest. Accept the input parameters from standard input, parse, perform computation, output the result to standard output. The other language has to parse. Using common interchange formats with library support (XML, CSV, JSON, Protocol buffers) simplifies the generating and parsing steps. Alternative to using standard io is to use a messaging service like. Other OS specific channels are also available, like , but being OS specific is hinders portability
there is a fortran transpiler f2c, obsoleted by binary compatibility
See also
[edit]- Source-to-source compiler
- Foreign function interface
- Language-independent specification
- Language binding
- Glue language
- API reuse
- JVM languages
- CLI Languages
References
[edit]- ^ "Cross-Language Interoperability". Microsoft Developer Network (msdn.microsoft.com). 2012. Retrieved 6 September 2012.
- ^ "Language Independence and Language-Independent Components".
- ^ http://www.oracle.com/technetwork/articles/java/dyntypelang-142348.html