The Linux Foundation

 
LsbInterpretedLanguage

From The Linux Foundation

Revision as of 14:00, 22 July 2006 by Mats (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

Contents

Issues with Interpreted Languages

Standardizing an interpreted language is a little different from standarizing a compiled language module. For the latter, it's mostly about defining a standard name and location for the libraries and documenting the library's ABI.

But for an interpreted language, we need to standardize and test several things.

Language Syntax

To a degree, we can rely on the language authors, and include their written language specifications by reference. The problem is that language syntax can change over time. When do we update our specifications?

Just as we require that C/C++ libraries have a stable ABI, we should require that interpreted languages have a stable syntax as a condition for inclusion. Deprecation policies should be reviewed; old syntax should be supported for a certain period of time. How does language evolution affect our promises of compatibility between versions of the LSB?

Standard Library

We need to test the standard library, both built-in functions and modules guaranteed to be there. As with compiled libraries, this can be done on two levels: symbol presence (as libchk works) and functional testing (like most of the other tests).

Most likely, these tests will have to be written in the target language. Thus, a preliminary requirement for standardizing a language might be for test harness bindings. At a minimum, one of the harnesses available (tetj, TET itself, or QM) should be reachable from the language, such that tests can be written in it.

Extension/Embed ABIs

Nearly all interpreted languages provide facilities for extensions to be written in a compiled language. Some, additionally, allow compiled applications to embed the language and use it within the app. In both cases, the language makes libraries available, whose ABI will need to be specified.

This task is most similar to standard LSB activities.

Extension Installation

Languages that allow extensions (either written in the language itself or in a compiled language) must somehow be registered with the interpreter. The process of doing this must be standardized, so that LSB applications can include language extensions.

Invocation

LSB-compliant interpreted applications should be as easy to run as compiled applications. This means that the application must be able to tell the system which interpreter it needs. Typically, this is done through the "hash-bang" syntax, which typically requires a full path to the interpreter. The "hash-bang" syntax is not in the LSB at this time. There should be a way for an app to indicate this that is portable across all LSB-compliant distributions.

Bindings for LSB Standards

Many of the other parts of the LSB have bindings in other languages. For example, GTK+ can be used in Perl, Python, and Mono, among others. App developers will likely want to use these bindings in their applications. How should we decide which of these bindings we will include in the standard?

Language Candidates


[Article] [Discussion] [View source] [History]