LISA

Language

Component

Architecture

Architectural Patterns

Notation

Implementation

References

Examples

FAQ

The Author


Language

Programming is about the construction of Languages. All that happens in a computer is communicated through a Language to the outside world. An Application that doesn't communicate with a Language is useless. All symbol manipulation in a computer is made possible with various Languages. A communication protocol is a Language. An API is a Language. A user interface is a Language. A programming language is a general purpouse Language.

The notion that everything either is a Language or is part of a Language may seem quite abstract at first and not very useful in the daily work of programming, but it is important that this abstraction is taken seriously. A computer manipulates symbols. To be able to communicate the meaning of the symbols and the result of the manipulations, a Language is necessary.

A Language is an abstraction. Layers of Languages form layers of abstractions that builds up the program. It is useful to let the Languages go from generic to Application specific in small, well defined steps. This simplifies reusability, increases flexibility and creates the foundation for good documentation.

A Language is complete, meaning it does not depend on vocabulary or axioms in Languages it does not extend. Languages with few dependencies are easier to reuse.

Language Definition

A Language is defined with by its syntax and semantics. The semantics of a Language is defined with axioms in a formal Language. Using the syntax and semantics, programs can be written, reasoned about and proven to be correct.

To be able to know what computational effect a program has, an implementation of the Language is necessary. This means that it is the implementation that creates the computational effect, and not the Language itself. A different Language implementation can yield a completely different computational effect for one and the same program.

LISA does not prescribe the Languages to use when syntax, semantics and implementations are defined. This choice is a central activity in system contruction and can not be simplified. It is important to choose Language semantics that make it easy to write programs that comply with functional specifications.

Reusability

Languages are reusable. Generic programming languages are the obvious example, but libraries and protocols are also good candidates. It is very important that a Language is well defined, or it will not be reusable. Reusability is the main reason LISA is so heavily based on Languages.

When constructing an Application, it is important to find the Languages used in the Application. With many well defined Languages, the opportunity for reuse increases.

Turing-complete Languages

A Turing-complete Language can be used to implement any other Language. A Turing-complete Language is often used as a Baseline Language in a system, and it is usually a generic Programming Language. A Turing-complete Language is suitable to be the base Language for other, more specialized Languages.

Language Extensions

A Language can be constructed from scratch or use an existing Language as base. For the latter, the extensive Language inherits the syntax and semantics from the base Language and extends it. A base Language is not allowed to extend an extensive Language, as they would collapse to the same Language. The base Language at the bottom is usually a generic Programming Language. Each Language together with its base Languages is a complete Language for a specific domain.

There are three types of extensions. Inclusive, exclusive and anti-inclusive.

An inclusive extension extends the semantics in such a way that a compiler for the base Language can compile the extensive Language as well.


STL extends C++ inclusively.

An anti-inclusive extension extends both the syntax and the semantics in such a way that a compiler for the extensive Language can compile the base Language as well.


C++ extends C anti-inclusively.

An exclusive extension extends both the syntax and the semantics in such a way that a compiler made for either Language can not compile the other.


ProC extends SQL exclusively.

Hybrid Languages

Multiple inclusions of Languages results in a hybrid Language. C with preprocessor statements is a hybrid Language. It needs a preprocessor to translate the preprocessor statements into pure C. ProC, which allows embedded SQL statements in a C program, is also a hybrid Language.


The hybrid Language ProC.

Interface

Most of the time, the interface to a Language is given by the single implementation of the Language. In some Architectures, a Language have several implementations with varying interfaces. Then it is useful to distingusih the Languages by adding the interface to the Language name.


Language with two interfaces.

The DL Language has two interfaces, one in XML and one in Java.

Other examples are TCP/IP for both C and Java, and a CORBA server Language for both C++ and Java.

Natural Languages

Often when constructing programs for users outside the software world, there exists a natural language for the domain where the program is used. It is important that this domain language is captured and defined with an implementation. It can often be a difficult task to define this language and a badly defined Domain Language is probably the main cause for dissatisfied users. To bridge the gap between users and programmers, various modeling techniques and Notations can be used. These models are descriptive and not executable, but they are nevertheless useful when the real Domain Language definition is created.

The reason natural languages are difficult to translate to formal definitions, is that every person's brain defines and implements the natural language a little different than everyone else. It then becomes a task for the development team to reprogram every user's brain to conform to the formal definition found in the program. This becomes easy when the formal language is as close as possible to all the user's natural languages.

Related Topics
Application
Architecture
Client-Server
Component
Examples
LISA
Model-View-Controller
Notation
Parser
Process
References
User Interface

Copyright (C) 2003, Marcus Andersson