Seite 2: Plattformunabhängigkeit

Inhaltsverzeichnis

VM sorgt für Plattformunabhängigkeit

Erlang ist dynamisch typisiert und kennt neben Integer- und Fließkommazahlen, Atomen und Bit-Strings noch Referenzen, Prozess- und Portidentifikatoren sowie Funktionsobjekte. Referenzen sind in einer Laufzeitumgebung immer eindeutig, Ports dienen der Kommunikation mit der Außenwelt. Als komplexere Datentypen gibt es Tupel, Listen und Strukturen. Letztere bildet Erlang intern jedoch transparent auf Tupel ab. Strings und Booleans sind keine eigenen Datentypen, sondern werden durch Listen von Integerwerten beziehungsweise die Atome true und false repräsentiert.

Ein wichtiges Sprachmittel ist die Endrekursion von Funktionen. Sie erlaubt die Implementierung aller Schleifen – auch der unendlichen – als rekursive Funktionen, ohne dass es zu Speicherüberläufen kommt. Auf dieser Basis sind auch die langlaufenden Prozesse möglich, die keinen linearen Durchlauf darstellen. In ihnen wird die Prozessfunktion immer wieder endrekursiv aufgerufen. Mit dem receive-Konstrukt greift sie auf die asynchrone Nachrichtenschlange des Prozesses zu und verarbeitet die Nachricht.

Für den Empfang der Nachrichten kommt das in Erlang überall gegenwärtige Pattern Matching zum Einsatz. Es erlaubt die einfache Analyse von Termen für die Zuweisung von Werten zu Variablen. Die letzte wichtige Eigenschaft ist die standardisierte Fehlerbehandlung, die einen aggressiven Programmierstil unterstützt.

Mit der Implementierung dieser Plattform fiel Ende 1987 die Wahl auf Erlang als Software-Basis für eine Telefonanlage. Der Prototyp dieser Anlage wurde 1989 fertiggestellt und erfüllte die in ihn gestellten Erwartungen voll. Im Rahmen einer Evaluierung im Projekt ACS/Dunder haben die Entwickler die Effizienzverbesserung im Design gegenüber der zu der Zeit üblichen Sprache PLEX mit einem Faktor zwischen 9 und 22 bewertet. War die erste Implementierung noch ein Interpreter auf der Basis von Prolog, folgten später ein Compiler sowie eine abstrakte Maschine für die Ausführung. Bis 1992 erreichte Erlang den Status der Produktionsreife und konnte für hardwarenahe Anwendungen mit nahezu Echtzeitanforderungen eingesetzt werden.

Die erste Ebene eines Erlang-Anwendungssystems sind Nodes. Jede gestartete virtuelle Maschine stellt einen solchen Node dar und ist mit weiteren Nodes vernetzbar. Diese können auf dem gleichen System oder weiteren Rechnern im Netz laufen. Allerdings ist es nicht möglich, dass ein Node in mehrere solcher Netze integriert ist. Eine Kommunikation über Netzgrenzen hinweg ließe sich via IP realisieren. Erlang/OTP bringt unter anderem umfangreiche CORBA-Bibliotheken mit, die im Erlang-Sprachgebrauch Module sind. Sie fassen Funktionen zusammen und bilden gleichzeitig einen Namespace. Innerhalb der Module werden die für eine externe Nutzung definierten Funktionen explizit exportiert.

-module(module_a).
-export([hello/2]).
hello(Place, Who) -> io:format("Hello -p, -p", [place(Place), Who]).
place(world) -> "world";
place(earth) -> "earth";
place(somewhere) -> "somewhere out there";
place(_Any) -> "wherever you are".

Ein Import ist im Gegensatz zu Sprachen wie Java oder C# nicht notwendig, jedoch möglich. Ein Aufruf der Funktionen erfolgt üblicherweise über modul:funktion(Arg1, Arg2, ...).

-module(module_b).
-export([call_hello/1]).
call_hello(Place) -> module_a:hello(Place, "Joe").

Alternativ werden Funktionen explizit importiert und benötigen dann das Modul-Präfix nicht mehr.

-module(module_c).
-export([call_hello/1]).
-import(module_a, [hello/2]).
call_hello(Place) -> hello(Place, "Joe").

Wie in der aus der Objektorientierung bekannten Polymorphie können die innerhalb der Module definierten Funktionen mehrfach in unterschiedlichen Implementierungen vorliegen. Solange die Anzahl der Argumente gleich ist, trennt ein Semikolon die Definitionen. Innerhalb der Funktionen trennen Kommata die Anweisungen sequenziell, und ein Punkt bezeichnet das Ende einer Definition.