Lispel

Lispel ist eine typisierte, objektorientierte funktionale Programmiersprache, die nach der (deutschen) Sprache modelliert wurde.

1. Die Idee

Nachdem ich mich erstmals mit funktionalen Programmiersprachen (hauptsächlich Scheme) beschäftigt hatte, war ich fasziniert von der Art und Weise, in der sie Probleme “beschreibend” lösen, ganz im Gegensatz zu imperativen Sprachen wie C++, Java oder Fortran. Eine Funktion zum Berechnen der Fakultät einer natürlichen Zahl n sieht imperativ in C++ so aus:

unsigned fakultaet(unsigned n)
{
  unsigned result(1);
  for(unsigned i(1); i<=n; ++i)
    result*=i;
  return result;
}

Das lässt sich als Algorithmus auffassen, wie mit einer Folge von Anweisungen zu einem gegebenen n die Fakultät berechnet werden kann:

1. Initialisiere result und i mit 1.
2. Multipliziere result mit i.
3. Inkrementiere i.
4. Falls i kleiner oder gleich n ist, gehe zu Schritt 2.
5. result enthält die Fakultät von n.

In Scheme sieht dieselbe Funktion zusammen mit ihrer Übersetzung in normale Sprache so aus:

(define fakultaet
  (lambda (n)
    (if (= n 1)
      1
      (* n (fakultaet (- n 1))))))

Die Fakultät von n ist für n gleich 1 1, sonst n mal die Fakultät von n minus 1.

Während der entsprechende Code in etwa gleich lang ist und die LISP-Syntax von Scheme möglicherweise verwirrend erscheint, finde ich, die funktionale Beschreibung ist in diesem Fall (und bei vielen anderen Problemen) der imperativen bei Weitem überlegen; das liegt mitunter auch daran, dass Menschen keine Computer sind und unsere Sprache viel besser mit der funktionalen Beschreibung als mit dem imperativen “Kochrezept” umgehen kann.

Aber ich gehe noch einen Schritt weiter: Ich glaube, dass die Sprache selbst eine funktionale Programmiersprache als eine von vielen Untermengen “enthält” bzw. dass es möglich ist, eine Untermenge der deutschen Sprache abzugrenzen, die nach strengen Regeln als funktionale Programmiersprache vom Computer interpretiert werden kann.

Als Beispiel und Vorbild dient mir dabei die Übersetzung der funktionalen Fakultätsfunktion von oben; anders als es (vor allem auch im imperativen Kontext) üblicherweise gern gemacht wird, assoziiere ich Funktionen nicht mit Verben, die eine auszuführende Aktion ausdrücken, sondern mit Substantiven, die für Eigenschaften oder Dinge stehen, die von anderen Dingen (“ihren Argumenten”) abhängen; nicht “bilde die Fakultät, indem...”, sondern explizit “die Fakultät ist...” — das erscheint mir als die natürlichste und verständlichste Möglichkeit.

Ebenso tief in unseren Gedanken und unserer Sprache verwurzelt sind “Begriffshierarchien” oder “-pyramiden”, wie sie schon Aristoteles beschrieben hat: Der Mensch ist ein Säugetier, Säugetiere sind Wirbeltiere, Wirbeltiere sind Tiere, Tiere sind Lebewesen und Lebewesen sind “Objekte”; dass Säugetiere damit alle allgemeinen Eigenschaften von Lebewesen teilen und mit eigenen, speziellen Eigenschaften ergänzen, ist vollkommen klar und wird mit unserer Sprache durch “Säugetiere sind Lebewesen” ausgedrückt.

In Programmiersprachen entspricht dieses Prinzip Objektorientierung und Polymorphismus; das ist der zweite Pfeiler, auf den sich das Design von Lispel stützt: Typisierung und Objektorientierung mit einer vollen Typenhierarchie, die auch alle eingebauten Typen wie Strings und Zahlen enthält, und die Möglichkeit bietet, eigene Klassen von Objekten durch Komposition und Vererbung zu definieren.

Summa summarum war es mein Ziel, mit Lispel eine Programmiersprache zu definieren, die nach der (deutschen) Sprache und allgemein der Art, zu denken, modelliert ist, und durch eine Untermenge, die direkt verständlich ist, ausformuliert wird, so dass Programme auch für Nichtprogrammierer ohne genaue Kenntnisse von Lispel verständlich sind. Diese Untermenge der deutschen Sprache, die die Formulierung von Lispel-Programmen regelt, trägt bei mir den Namen Depel. Allerdings sollte Depel nie ein AI-System zum Verständnis menschlicher Sprache werden; dieses Ziel halte ich heutzutage noch für zu weit gesteckt, um wirklich Erfolge zu erzielen; mit dem Ansatz, eine wohldefinierte Untermenge auszusondern, so dass sie als “direkt verständliche und formulierbare Programmiersprache” dienen kann, bin ich jedoch sehr wohl zu einem brauchbaren und für mich als Proof-of-concept zufriedenstellenden Ergebnis gekommen.

2. Struktur des Lispel-Systems

2.1 Das Typensystem

Alle Datenwerte in Lispel haben einen assoziierten Datentyp; diese Typen bilden eine Hierarchie analog zur Klassenhierarchie von C++: Ein Typ kann beliebig viele Supertypen besitzen, auch keinen oder mehr als einen. In dieser Hierarchie ist Upcasting automatisch und explizit beliebig möglich, Downcasting jedoch nicht (es sei denn, es werden Funktionen für diesen Zweck definiert).

Seien z. B. ‘Baum’ und ‘Hat-Blätter’ die Supertypen von ‘Laubbaum’, dann kann jeder Datenwert vom Typ ‘Laubbaum’ explizit oder implizit als ‘Baum’ oder ‘Hat-Blätter’ verwendet werden; umgekehrt kann jedoch, außer durch eine benutzerdefinierte Funktion, aus einem ‘Baum’ kein ‘Laubbaum’ gemacht werden.

Es ist ein Fehler, wenn beim Upcasting (auf Grund von unglücklicher Mehrfachvererbung) eine Mehrdeutigkeit auftritt; dies muss vermieden werden, eine Möglichkeit dazu stellt explizites Upcasting auf einen Zwischentyp dar, so dass beide dieser Casts eindeutig sind und zusammen den gewünschten Supertyp ergeben.

Auch die grundlegenden Zahlen- und String-Typen von Lispel werden als ganz normale Typen in dieser Hierarchie angesehen und können als Supertypen dienen:

String

Ein Textstring, also quasi ein Array oder eine Aneinanderreihung von Zeichen.

Zahl

Eine Gleitkommazahl.

Ganzzahl

Eine Ganzzahl; Zahl ist ein Supertyp der Ganzzahl, eine Ganzzahl kann also jederzeit den Platz einer Gleitkommazahl einnehmen.

Bedingung

Ein Bool’scher Wert, d. h. ein Wahrheitswert.

2.2 Funktionen

Funktionen bilden natürlich den Grundstock von Lispel als funktionaler Programmiersprache; sie erzeugen (“berechnen”) einen Rückgabewert aus den übergebenen Argumentwerten, können und dürfen jedoch keinerlei Nebeneffekte besitzen. Ihr Ergebnis ist einzig und allein der Rückgabewert, es kommt in keinem Fall zu einer Statusänderung.

In Lispel besteht die Signatur einer Funktion aus den Typen der erwarteten Argumente, der Typ des Rückgabewertes wird jedoch nicht explizit angegeben. Beim Aufruf werden alle Argumente “per Wert” übergeben und zum exakten Typ in der Signatur upgecastet.

Es ist auch möglich, Argumenten den speziellen “Typ” Irgendwas zuzuweisen; für ein solches Argument kann jeder beliebige Wert übergeben werden, der dann direkt und ohne Casting in den Körper der Funktion übernommen wird. Auf diese Weise sind “generische Funktionen” möglich, wie Berechnung des größeren zweier Werte beliebigen Typs (sofern Vergleich für die beiden Typen implementiert ist).

Lispel erlaubt es, Funktionen zu überladen: Derselbe Name kann mehreren Funktionen gegeben werden, die sich in Anzahl und/oder Typen ihrer Argumente unterscheiden. Beim Aufruf einer Funktion werden zuerst die Argumente ausgewertet und auf ihren Typ hin überprüft; anschließend werden alle Funktionen mit dem gesuchten Namen mit den gegebenen Argumenten verglichen. Falls genau eine mit ihnen übereinstimmt, wird sie aufgerufen; es ist ein Fehler, wenn keine oder eine nicht eindeutige Möglichkeit gefunden wird.

Übereinstimmung wird festgestellt, wenn

1. die Anzahl an Argumenten gleich ist, und
2. jeder Argumenttyp der Signatur derselbe oder ein Supertyp des Typs des gewünschten Argumentwertes ist.

2.3 Objektorientierung

Objekte in Lispel sind eine Zusammenfassung von “Unterobjekten”. Für jeden Supertyp, von dem sich ein neuer Typ ableitet, und für jede Membervariable, die der Typ zusätzlich besitzt, wird ein solches Unterobjekt benötigt.

Neue Objekte werden durch eine automatisch erzeugte Konstruktorfunktion angelegt, der als Argumente alle Werte übergeben werden müssen, mit denen die Unterobjekte belegt werden sollen; also zuerst die Werte in allen Supertypen und danach die gewünschten Werte der Membervariablen, jeweils in der richtigen Reihenfolge.

Upcasting zu einem Supertyp ist anschließend einfach der Vorgang, anstatt des Objekts selbst das entsprechende Unterobjekt zu verwenden, also quasi ein impliziter Zugriff auf diese “Membervariable”. Für den Zugriff auf die Unterobjekte, die zu richtigen Membervariablen gehören, werden auch automatisch Accessor-Methoden definiert.

2.4 Side-Effects für IO, Variablen und Co.

Obwohl Lispel von Grund auf als funktionale Programmiersprache entworfen wurde, gibt es natürlich auch Probleme, die nur schwer oder sogar gar nicht rein funktional lösbar sind. IO ist eines der Probleme, die vollkommen ohne Side-Effects nicht lösbar sind.

In Lispel kann es deshalb neben Funktionen auch Actions geben, die ebenfalls auf dieselbe Art und Weise Argumentwerte bekommen können (und auch überladen werden dürfen), jedoch nicht einen Rückgabewert produzieren, sondern Nebeneffekte ausführen (sie entsprechen Funktionen in C/C++/Java mit dem Rückgabetyp void).

Der Code einer Action ist eine Abfolge von Unteractions, die der Reihe nach ausgeführt werden; iterative Konstrukte sind mit Hilfe von Rekursion der Action möglich. Für bedingte Ausführung sind Action-Literale oder -Werte nötig:

Es gibt einen speziellen Datentyp, Side-Effect, dessen Werte einen konkreten Nebeneffekt beschreiben (entweder in Form eines Action-Aufrufs mit bereits ausgewerteten und bekannten Argumenten oder als Sequenz von Action-Aufrufen, ähnlich zum Körper einer Action selbst). Diese Werte können nun von Funktionen “erzeugt” werden, oder durch den wertbasierten Bedingungskonstrukt von Lispel (See section Deutsch als Programmiersprache) von einem Test abhängen. Eine spezielle eingebaute Action erlaubt es, diese Nebeneffekte letztendlich auszuführen. Damit lässt sich eine bedingte Ausführung einer Action so (als Pseudocode) formulieren:

do /* Dies ist die eingebaute Action zur Ausführung */
  if bedingung
    ! action /* Action-Aufruf als Wert */
  else
    nichts /* Side-Effect-Wert für ``No-Operation'' */

Ein anderer eingebauter Datentyp ist die Variable, quasi ein Pointer auf einen beliebigen anderen Datenwert; mit Hilfe von Variablen ist Übergabe von Argumenten per Referenz möglich, auf diese Weise können Actions (z. B. Input-Actions) Werte an den Aufrufer zurück geben. Definiert werden können Variablen gemischt mit Unteractions im Code einer Action-Definition. Für das Setzen von Variablen sind eingebaute Actions zuständig, denen die Variable und der gewünschte neue Wert übergeben werden muss.

3. Deutsch als Programmiersprache

Die eigentliche Programmiersprache zum Lispel-System ist Depel (See section Struktur des Lispel-Systems), das als möglichst intuitive Untermenge der deutschen Sprache entworfen wurde. Dieses Kapitel beschreibt, wie die Features und Möglichkeiten von Lispel ausformuliert werden.

3.1 Kommentare

Auch in Depel gibt es natürlich Kommentarkonstrukte, nämlich mehrzeilig im C-Stil (zwischen /* und */, Verschachtelung nicht erlaubt) und einzeilig im C++-Stil (alles, was in einer Zeile nach // kommt, wird ignoriert):

/* Ich bin ein
 * mehrzeiliger Kommentar
 */

hier steht code // und hier ein Kommentar

3.2 Datenwerte

3.2.1 Literale

Literale stellen die einfachste und grundlegendste Art dar, Datenwerte in Depel anzugeben:

‘"Hallo, Welt!"’

String-Literale werden in doppelten Anführungszeichen " geschrieben, der Backslash \ dient als Maskierungszeichen für Anführungszeichen oder Backslash-Zeichen im String selbst.

‘-42’

Ganzzahl-Literale werden als Zahlen im Dezimalsystem angegeben.

‘5.23’

Gleitkomma-Literale werden mit einem Punkt . als Dezimaltrennzeichen geschrieben; kommt er vor, handelt es sich um Gleitkommazahlen (ansonsten wird das Literal als Ganzzahl angenommen).

Falls nach einem Zahlenliteral ein .-Zeichen als Definitionsende folgt, sollte ein Leerzeichen eingefügt werden (‘... 42 .’ statt ‘... 42.’), damit der Punkt nicht als Teil des Zahlenliterals aufgefasst wird!

Für Bedingungen sind die beiden Konstanten wahr und falsch vordefiniert und können als Bedingungsliterale angesehen werden.

3.2.2 Funktionsaufrufe

Die wohl wichtigste Art, zu Datenwerten zu kommen, ist, als Rückgabewerte von Funktionsaufrufen; die Formulierung in Depel ist:

Artikel Funktion [von] Argumente

Das von muss genau dann angegeben werden, wenn mehr als ein Argument übergeben wird; Funktionsaufrufe ohne Argumente sind nicht erlaubt, dafür sind Konstanten (siehe unten) die Lösung.

// Rufe Sinus mit einem Argument (dem Wert alpha) auf
der Sinus alpha

// Berechne die Summe von zwei bzw. drei Argumenten (Zahlenliterale)
die Summe von 40 und 2
die Summe von 1, 2 und 3

// Berechne das Produkt von zwei Summen
das Produkt von der Summe von a und b und der Summe von 2 und x

3.2.3 Bedingungsabfragen

Ein grundlegendes Feature jeder Programmiersprache sind Bedingungen; in Lispel sind sie auf Ebene der Werte implementiert, d. h., in Depel gibt es einen Konstrukt, der je nach dem Wert einer Bedingung alternativ einen von zwei möglichen Werten annimmt:

fuer Bedingung Wert 1 , sonst Wert 2

Falls Bedingung (muss vom Typ Bedingung sein) wahr ist, hat der gesamte Ausdruck den Wert von Wert 1, ansonsten den von Wert 2.

// Liefert beide Male 42
fuer wahr 42, sonst 24
fuer falsch 24, sonst 42

3.2.4 Casts

Casts (Upcasting) in der Typenhierarchie (See section Das Typensystem) werden durch das Schlüsselwort als ausgedrückt; um Mehrdeutigkeiten in der Grammatik zu verhindern, gibt es eine eigene Casting-Syntax für Rückgabewerte von Funktionsaufrufen.

Wert als Typ
Artikel Funktion als Typ [von] Argumente

// Einfacher Upcast zum Typ Baum
einLaubbaum als Baum

// Hier wird die Summe von 3 und 5 berechnet, 5 als Gleitkommazahl...
die Summe von 3 und 5 als Zahl
der Sinus alpha als Zahl

// ...dagegen hier wird die Summe bzw. der Sinus gecastet
die Summe als Zahl von 3 und 5
der Sinus als Zahl alpha

3.2.5 Definition von Konstanten

Auf globaler Ebene können Konstanten definiert werden, die einfach einem Namen einen festen Wert zuordnen, der anschließend nicht mehr überschrieben werden kann:

Sei Name Wert .

Dies definiert die Konstante mit Namen Name auf den Wert Wert.

Sei Pi 3.14159.
Sei Grusz "Hallo, Welt!".
Sei Null der Sinus Pi.

3.3 Funktionen

Funktionsdefinitionen bestehen aus der Signatur der Funktion (Name und Argumente) und dem Funktions-Code. Der Code ist ein Datenwert, der sich auf die Argumente beziehen kann, und nach seiner Auswertung als Rückgabewert der Funktion dient. Definiert wird eine Funktion so:

Artikel Name von Argumente ist Wert .

Anders als beim Aufruf von Funktionen ist hier das von immer anzugeben, auch bei ein-argumentigen Funktionen. Die Argumente selbst bestehen jeweils aus Artikel, Typ und Name. Der Funktionscode (Wert) kann sich im Fall rekursiver Funktionen natürlich auch auf die definierte Funktion selbst beziehen.

Das Quadrat von der Zahl x ist das Produkt von x und x.
Die Quadratsumme von der Zahl a und der Zahl b ist
  die Summe von dem Quadrat a und dem Quadrat b.
Die Fakultaet von der Ganzzahl n ist
  fuer n gleich 0 1,
  sonst n mal die Fakultaet n minus 1 .

3.4 Operatoren

In Depel gibt es die Möglichkeit, unäre und binäre Operatoren ähnlich zu Funktionen zu definieren, damit sich gewisse Ausdrücke natürlicher formulieren lassen (wie z. B. ‘a plus b’ statt ‘die Summe von a und b’).

// Unärer Operator mit einem Argument
Operator Typ Argumentname ist Wert .

//  Binärer Operator mit zwei Argumenten
Typ1 Argument1 Operator Typ2 Argument2 ist Wert .

Wert ist hier ganz gleich zu Funktionen der Ausdruck, der ausgewertet wird, um zum Ergebnis zu kommen. Anders als bei Funktionen bestehen die Argumente hier jedoch nur aus ihrem Typ und dem Namen, ohne Artikel. Es ist jedoch auch hier möglich, Operatoren zu “überladen”.

Zahl a plus Zahl b ist die Summe von a und b.
nicht Bedingung c ist die Verneinung von c.
nicht Ganzzahl x ist 0 minus x.

Aufgerufen werden Operatoren in der Form:

Operator Wert // Unär
Wert1 Operator Wert2 // Binär

Intern sind Operatoren und Operatoraufrufe vollkommen gleichbedeutend zu Funktionen und Funktionsaufrufen. Allerdings ist es, um Mehrdeutigkeiten zu vermeiden, nicht erlaubt, “komplexe” Werte (wie Funktionsaufrufe) als Wert1 eines binären Operators zu verwenden; daher sollten Operatoren wirklich nur als Abkürzungen für auch anderweitig benutzbare Features dienen, und sind vor allem für Arithmetik, Vergleiche und Ähnliches gedacht:

5 plus x
nicht a gleich b // Unäres ‘nicht’, binäres ‘gleich’

3.5 Objektorientierung

Definitionen von neuen Typen sehen in Depel so aus:

// Nur Komposition, nur Vererbung oder beides
ArtikelU Name hat Members .
ArtikelU Name ist Supers .
ArtikelU Name ist Supers ; und hat Members .

// Eine Member-Angabe
ArtikelB Typ Name

// Eine Super-Angabe
ArtikelU Typ [( ArtikelB Name )]

Hier bedeutet ArtikelU einen unbestimmen Artikel und ArtikelB einen bestimmten. Auch Super-Typen können Namen gegeben werden (müssen jedoch nicht), dann ist das entsprechende Unterobjekt nicht nur durch einen Cast, sondern auch wie eine normale Membervariable durch einen Accessor greifbar.

Die automatisch erzeugte Konstruktor-Funktion hat den Namen Neu-Name, Accessor-Methoden die Form Typ-Member.

// Definiere drei neue Typen
Ein Vektor hat die Zahl x und die Zahl y.
Eine Blume ist eine Pflanze.
Ein Haus ist eine Wohnung und ein Gebäude (das Bauwerk);
  und hat den Garten Vorgarten.

// Erzeuge einen Vektor und eine Blume
der Neu-Vektor von 5 und 2.3
die Neu-Blume meinePflanze

// Zugriff auf Member-Variablen
das Haus-Bauwerk haus
das Vektor-x v

3.6 Actions und Side-Effects

3.6.1 Action-“Literale”

Action-Literale sind die einfachste Form von Action-Werten (See section Side-Effects für IO, Variablen und Co.); sie sind ein Wert (See section Datenwerte), der den Side-Effect beschreibt, eine gewisse Action mit festdefinierten und bereits ausgewerteten Argumenten aufzurufen.

Mit dem Schlüsselwort mache kann ein Action-Wert ausgeführt werden (oder es kann ein neuer Action-Wert erzeugt werden), es ist also quasi die Umkehrung zum Erzeugen von Side-Effects. Wichtig ist, dass dabei z. B. auch Bedingungskonstrukte erlaubt sind, um je nach dynamischem Status eine bestimmte Action auszuwählen.

Action mit Argumente !
mache Wert !

Diese Werte können beliebig verwendet werden, wie von Funktionen berechnet und zurückgegeben oder irgendwo gespeichert.

Sei meineAktion gib-aus mit stdout, "Hallo, Welt!" und newline!.
mache fuer x gleich 0 nichts,
  sonst gib-aus mit stdout, 3 durch x und newline!!
!

3.6.2 Sequenzen von Actions als Werte

Sollen mehrere Actions zusammen einen Side-Effect ergeben, ist es oft nicht günstig, dass bei Action-Literalen die Argumente schon bei der Erstellung ausgewertet werden; damit ist es z. B. nicht möglich, eine Variable zu setzen und anschließend mit dem neuen Wert etwas anzufangen, da die Variable zum Zeitpunkt der Auswertung noch den alten Wert besitzt.

Für solche Fälle gibt es einen speziellen Konstrukt, um mehrere Actions ohne frühe Auswertung hintereinander zu einem Side-Effect zusammen zu fassen:

Literal1 & Literal2 & Literal3 ...

Der entstandene Side-Effect-Wert hängt allerdings vom aktuellen Kontext ab, und ist nur für die Verwendung mit Bedingungskonstruktren gedacht, er sollte nie als Rückgabewert einer Funktion verwendet werden!

mache fuer x gleich 0 nichts,
  sonst gib-aus mit stdout und 3 durch x! &
  tueWasAnderes mit x!
!

3.6.3 Definieren von eigenen Actions

Eigene Actions können ähnlich zu Funktionen definiert werden, indem ihnen eine Signatur und ein Code gegeben wird:

Name bedeutet mit Argumente : Code .

Die Argumente sind dabei wie bei Funktionen eine Liste der einzelnen Argumente, jeweils als Artikel, Typ und Name. Der Code ist eine Folge von einer oder mehrerer Actions, formuliert als einzelne Literale (oder mache-Konstrukte). Auch bei Actions ist Rekursion möglich, eine Action kann sich also selbst im Laufe des Codes aufrufen!

Im Code können auch Konstanten definiert werden, die lokal zur Ausführung der Action sind.

verarbeite bedeutet mit dem Inputstream in:
  sei x die Variable EOF!
  lese-Byte mit in und x!
  mache fuer EOF gleich dem Wert x nichts,
    sonst
      macheEtwas mit dem Wert x! &
      verarbeite mit in!
  !.

3.7 Shell-Features

Bis jetzt wurden eigentlich nur Definitionen von Konstanten, Funktionen und Actions in Depel beschrieben; um diese Definitionen auch zu nützen, müssen sie irgendwie ausführbar/aufrufbar sein. Dafür sind die “interaktiven Features” von Depel als “Shell” da (obwohl sie natürlich auch in einer Programm-Code-Datei möglich sind): Berechnen und ausgeben von Werten und ausführen von Actions.

Wert ? // Wertet Wert aus und zeigt das Ergebnis an
Action ! // Führt die Action aus

Wert ist hier ein Datenwert (See section Datenwerte), Action ein Action-Literal wie z. B. im Code einer Action (See section Actions und Side-Effects).

6 mal 7?
gib-aus mit stdout und "Hallo, Welt!"!? // Zeigt als Wert an
gib-aus mit stdout und "Hallo, Welt!"!! // Fürht aus

A. Beispiele für Depel in Aktion

In diesem Abschnitt werden einige der Beispiele, die in der Lispel-Distribution mitgeliefert werden, angeführt und genauer erklärt; der Code dazu und noch andere Beispiele sind im Verzeichnis ‘examples’ zu finden.

A.1 Fakultät

Die Berechnung der Fakultät einer natürlichen Zahl ist ein beliebtes erstes Beispiel für funktionale Programmiersprachen allgemein, und wurde bereits in der Einführung (See section Die Idee) erwähnt.

So sieht eine Funktion in Depel aus, die die Fakultät rekursiv berechnet (der gesamte Code findet sich in ‘examples/factorial.dpl’):

Die Fakultaet von der Ganzzahl n ist
  fuer n kleiner-gleich 1 1,
  sonst n mal die Fakultaet n minus 1 .

In Depel ergibt sich hierbei eine ziemlich verständliche Formulierung, das ist wohl eines der Musterbeispiele für die Idee hinter Depel. Um noch ein paar Fakultäten zu berechnen:

die Fakultaet 0? // 1
die Fakultaet 1? // 1
die Fakultaet 5? // 1*2*3*4*5=120

A.2 Hallo, Welt!

Dieser Klassiker darf natürlich nicht fehlen, obwohl er für eine funktionale Programmiersprache nicht sehr gut geeignet ist, da ja der einzige Zweck dieses Programms IO ist. In Depel ist es nicht mehr als ein einziger Aufruf einer Bibliotheksfunktion:

gib-aus mit stdout, "Hallo, Welt!" und newline!!

Dieser Code als Programmdatei ist ‘examples/hello.dpl’ in der Distribution.

A.3 Berechnen von Quadratwurzeln

Das Heron’sche Verfahren ist ein iterativer Algorithmus, um mit guter Konvergenz die Quadratwurzel von Zahlen zu berechnen (es ist ein Spezialfall des Newton-Verfahrens): Von einem beliebig gewählten Startwert aus wird in jeder Iteration der neue Wert neu, der die Wurzel aus x immer besser approximiert, aus dem alten Wert alt berechnet:

neu=0.5*(alt+x/alt)

Eine Implementierung dieses Verfahrens in Depel ist als Beispiel ‘examples/heron.dpl’ bei Lispel enthalten. Das Herz dieses Programms ist die Funktion Heronwurzel, die zur Zahl x und dem aktuellen Iterationswert a die Wurzel durch Rekursion berechnet, bis das Quadrat der gefundenen Wurzel hinreichend genau an x heranreicht (um weniger als die Konstante Epsilon abweicht):

Die Heronwurzel von der Zahl x und der Zahl a ist
  fuer Epsilon groeszer dem Abstand von x und dem Quadrat a a,
  sonst die Heronwurzel von x und 0.5 mal a plus x durch a.

Als guten Startwert wähle ich 0.5*x, damit lässt sich nun die eigentliche Wurzelfunktion als Wrapper um Heronwurzel formulieren:

Die Wurzel von der Zahl x ist die Heronwurzel von x und 0.5 mal x.

Zum Schluss noch ein paar Testberechnungen von Wurzeln:

die Wurzel 1?
die Wurzel 2?
die Wurzel 256?

A.4 Vektoren

Das Beispiel ‘examples/vectors.dpl’ zeigt, wie in Depel ein 2-dimensionaler reeller Vektor als neuer Typ zusammen mit grundlegenden Operationen definiert werden kann:

Ein Vektor hat die Zahl x und die Zahl y.

Die Summe von dem Vektor a und dem Vektor b ist
  der Neu-Vektor von
    der Summe von dem Vektor-x a und dem Vektor-x b und
    der Summe von dem Vektor-y a und dem Vektor-y b.

Das Produkt von der Zahl alpha und dem Vektor v ist
  der Neu-Vektor von
    alpha mal dem Vektor-x v und alpha mal dem Vektor-y v.

Das Skalarprodukt von dem Vektor a und dem Vektor b ist
  die Summe von
    dem Produkt von dem Vektor-x a und dem Vektor-x b und
    dem Produkt von dem Vektor-y a und dem Vektor-y b.

Mit diesen Definitionen kann z. B. der Schwerpunkt eines Dreiecks als “Mittelwert” der drei Ortsvektoren seiner Eckpunkte berechnet werden:

Der Schwerpunkt von dem Vektor a, dem Vektor b und dem Vektor c ist
  das Produkt von 1 durch 3.0 und
    a plus die Summe von b und c.

Und mit Hilfe des Skalarprodukts kann geprüft werden, ob zwei Vektoren orthogonal auf einander stehen:

Die Orthogonalitaet von dem Vektor a und dem Vektor b ist
  0 gleich dem Skalarprodukt von a und b.

Werden nun ein paar Vektoren definiert, können diese Funktionen auch gleich getestet werden:

Sei A der Neu-Vektor von 0 und 0 .
Sei B der Neu-Vektor von 0 und 1 .
Sei C der Neu-Vektor von 1 und 0 .
Sei X B plus C.

der Schwerpunkt von A, B und C? // (1/3, 1/3)

die Orthogonalitaet von B und C? // Ja
die Orthogonalitaet von A und X? // Ja
die Orthogonalitaet von X und B? // Nein

A.5 Rot13-Prozessor

Rot13 bezeichnet eine einfache Art der Unkenntlichmachung von Text, indem einfach alle Buchstaben im Alphabet um 13 Zeichen verschoben werden (wie bei der Cäsar-Verschlüsselung), die z. B. in Usenet-Postings gern verwendet wird. Erneute Anwendung von Rot13 stellt den ursprünglichen Text wieder her, da alle Buchstaben in Summe um 26 Zeichen verschoben wurden, also wieder am Ausgangsplatz landen.

‘examples/rot13.dpl’ enthält ein Depel-Programm, das von seiner Standardeingabe Text liest, ihn mit Rot13 ver- bzw. entschlüsselt, und das Ergebnis auf die Standardausgabe schreibt.

Zuerst werden ein paar Konstanten definiert, wo sich im Zeichensatz (ASCII) der zu verschlüsselnde Buchstabenbereich (Groß- und Kleinbuchstaben) befindet:

Sei Ascii_A 65 .
Sei Ascii_a 97 .
Sei Buchstaben 26 .

Das KleinbuchstabeSein von der Ganzzahl c ist
  die Konjunktion von c kleiner-gleich Ascii_a plus Buchstaben und
  c groeszer-gleich Ascii_a.

Das GroszbuchstabeSein von der Ganzzahl c ist
  die Konjunktion von c kleiner-gleich Ascii_A plus Buchstaben und
  c groeszer-gleich Ascii_A.

Damit kann nun die Rot13-Verschlüsselung eines Zeichens (Verschiebung falls Buchstabe, sonst wird nichts verändert) und darauf aufbauend auch die eines ganzen Strings als Funktion definiert werden:

Das Rot13 von der Ganzzahl c ist
  fuer das GroszbuchstabeSein c
    Ascii_A plus dem Rest von 13 plus c minus Ascii_A und 26,
  sonst fuer das KleinbuchstabeSein c
    Ascii_a plus dem Rest von 13 plus c minus Ascii_a und 26,
  sonst c.

Das Rot13 von dem String str und dem String cur ist
  fuer die Gleichheit von der Laenge str und der Laenge cur cur,
  sonst das Rot13 von str und der Verkettung von cur und
    des Rot13 des Indexzeichen von str und der Laenge cur.
Das Rot13 von dem String str ist das Rot13 von str und "".

Zum Schluss wird noch eine rekursive Action definiert, die so lange Zeilen von stdin liest, bis Ctrl-D als End-Of-Input eingegeben wird, und jeweils die Rot13-Verschlüsselung jeder Zeile ausgibt; diese wird am Ende des Programms noch gestartet (der Parameter dummy wird nicht verwendet und ist nur da, weil Actions Parameter bekommen müssen):

rot13e bedeutet mit der Ganzzahl dummy:
  sei c die Variable EOF!
  sei line die Variable ""!
  lese-Byte mit stdin und c!
  mache
    fuer EOF gleich dem Wert c nichts,
    sonst 
      lese-Zeile mit stdin und line! &
      gib-aus mit stdout,
        dem Rot13 der Verkettung von dem Wert c und dem Wert line
        und newline! &
      rot13e mit dummy!
  !
  .

rot13e mit 0!!

B. Die Depel-Laufzeitbibliothek

Hier sollen die eingebauten Definitionen (Typen, Funktionen, Operatoren und Actions) von Lispel und Depel kurz beschrieben werden; in der Implementierung gibt es zwei Arten, nämlich direkt eingebaut (im Quellcode selbst implementiert, für grundlegende Features, die nicht durch andere, bereits vorhandene möglich sind) und durch eine automatisch geladene Depel-Bibliothek in Depel selbst geschrieben für Definitionen, die hilfreich sein können aber allein durch schon eingebaute Features ausdrückbar sind. In der Anwendung macht diese Unterscheidung nichts aus, dennoch wird erwähnt werden, welche Definitionen zu welcher Art gehören.

B.1 Arithmetik

Eingebaute arithmetische Funktionen sind:

Summe(Zahl, ...)

Produkt(Zahl, ...)

Berechnung von Summe oder Produkt von einer (nicht sehr interessant) bis beliebig vielen Zahlen. Sind alle diese Zahl-Werte vom Typ Ganzzahl, so wird ganzzahlig gerechnet, ansonsten ist das Ergebnis eine Gleitkommazahl.

Differenz(Zahl, Zahl)

Quotient(Zahl, Zahl)

Differenz bzw. Quotient zweier Zahlen. Sind es wieder zwei Ganzzahlen, wird ganzzahlig gerechnet und das Ergebnis der Division ist der ganzzahlige Anteil.

Rest(Ganzzahl, Ganzzahl)

Berechnet den Rest der Division von zwei Ganzzahlen.

In der Depel-Bibliothek werden dazu definiert:

plus

minus

mal

durch

modulo

Binäre Operatoren, akzeptieren Irgendwas für beide Argumente, und rufen einfach die entsprechende Funktion wie oben auf; für nicht-Zahl-Argumente natürlich nur dann möglich, wenn sie für diese Typen überladen wurde.

Absolutbetrag(Zahl)

Berechnet den Absolutbetrag einer Zahl.

Abstand(Irgendwas, Irgendwas)

Berechnet generisch den “Abstand” zweier Werte, als Absolutbetrag ihrer Differenz (für nicht-Zahlen nur mit Überladungen möglich).

Quadrat(Irgendwas)

Berechnet das “Quadrat” eines Wertes als Produkt mit sich selbst.

Epsilon

Eine Konstante, die auf einen kleinen Wert (recht willkürlich) als Vorschlag für die Genauigkeit von Berechnungen definiert ist.

B.2 Strings

Eingebaute Funktionen zum Arbeiten mit Strings:

Verkettung(...)

Argumente sind ein bis beliebig viele Strings oder Ganzzahlen; alle Argumente werden zu einem neuen String zusammengehängt, wobei Ganzzahlen als Zeichen mit entsprechendem Code aufgefasst werden.

Laenge(String)

Gibt die Länge eines Strings (Anzahl an Zeichen) zurück.

Indexzeichen(String, Ganzzahl i)

Gibt das i-te Zeichen im String zurück, Indizierung beginnt bei 0. Die Rückgabe erfolgt als Ganzzahl, die als Wert den Zeichencode hat. Es ist ein Fehler, wenn i negativ oder nicht kleiner als die Länge des Strings ist!

Substring(String, Ganzzahl ab, Ganzzahl len)

Gibt den Teil des Strings beginnend bei ab und mit der Länge len zurück.

B.3 Bedingungen und Vergleiche

Das System für Vergleiche in Lispel geht davon aus, dass nur die Operationen Gleichheit und KleinerAls für zwei gegebene Argumenttypen definiert sein müssen, und die anderen Operationen (Ungleichheit, GroseszerAls, KleinerGleich und GroszerGleich) dadurch definiert sind.

Eingebaute logische Operationen und Vergleichsfunktionen:

Verneinung(Bedingung)

Konjunktion(Bedingung, Bedingung)

Disjunktion(Bedingung, Bedingung)

Logisches Nicht, Und und Oder.

Ungleichheit(Irgendwas, Irgendwas)

Definiert die ungleich-Operation generisch als Verneinung der Gleichheit.

GroeszerAls(Irgendwas, Irgendwas)

KleinerGleich(Irgendwas, Irgendwas)

GroeszerGleich(Irgendwas, Irgendwas)

Definiert die jeweiligen Vergleichsoperationen durch KleinerAls.

Gleichheit(..., ...)

Gleichheitsoperation für die eingebauten Typen (Zahl/Ganzzahl, String, Bedingung).

KleinerAls(..., ...)

Definiert den Vergleich für Zahl und Ganzzahl sowie für String als lexikalischen Vergleich.

Operatordefinitionen in der Depel-Bibltiothek:

nicht

Unärer Operator für Verneinung.

und-auch

oder

Binäre Operatoren für Konjunktion und Disjunktion.

gleich

ungleich

kleiner

kleiner-gleich

groeszer

groeszer-gleich

Generische binäre Operatoren für die jeweiligen Vergleichsfunktionen.

B.4 Variablen

Variablen sind spezielle Datenwerte, quasi Pointer, die intern noch einen anderen Wert “besitzen”, den sie durch eine Action ändern können. Durch Übergabe einer Variable kann somit ein Wert per-Referenz an eine Action übergeben werden, und so z. B. als Rückgabewert der Action dienen.

Eingebaute Definitionen:

Variable

Variable(Irgendwas)

Der Datentyp für Variablen und sein “Konstruktor”, eine Funktion, die eine neue Variable mit dem angegebenen Anfangswert erzeugt.

Wert(Variable)

Funktion, die den Wert einer Variablen ermittelt.

setze Variable, Irgendwas

Action, um den Wert der Variablen zu ändern.

B.5 Streams und IO

Für IO ist in Lispel das Konzept von Streams eingebaut, zusammen mit Actions, die von ihnen lesen oder schreiben:

Stream

Inputstream

Outputstream

Die Typen für Streams; Inpustream und Outputstream sind Untertypen von Stream.

Binaerdatei-Outputstream(String)

Textdatei-Outputstream(String)

Binaerdatei-Inputstream(String)

Textdatei-Inputstream(String)

Öffnet eine Datei mit dem übergebenen Namen auf die entsprechende Art und Weise, und gibt den erzeugten Inputstream bzw. Outputstream zurück. Geschlossen wird die Datei automatisch, wenn die Arbeit beendet ist (d. h., der Stream-Wert nicht mehr benötigt wird).

String-Inputstream(String)

Erzeugt einen speziellen Inputstream, der genau den Inhalt des übergebenen Strings als Daten zum Lesen bereit stellt.

gib-aus Outputstream, Irgendwas, ...

Gibt den Wert oder die Werte in einer vom Typ abhängigen Art und Weise (gut lesbar) auf den Stream aus.

lese-ein Inputstream, Variable, ...

Liest vom Stream einen oder mehrere Grundwerte (Zahl, Ganzzahl oder String, Format wie in Depel selbst) ein und speichert sie in die übergebenen Variablen.

schreibe Outputstream, String

Gibt den String direkt (d. h., Zeichen für Zeichen ohne Anführungszeichen oder dergleichen) aus.

schreibe-Byte Outputstream, Ganzzahl

Schreibt die Zahl, interpretiert als Byte-Wert von 0 bis 255, als einzelnes Byte auf den Stream. Es ist ein Fehler, wenn der Zahlenwert außerhalb dieses Bereichs liegt!

lese-Zeile Inputstream, Variable

Liest eine Zeile als String ein (ohne schließendes \n) und speichert ihn in die übergebene Variable.

lese-String-nach-Laenge Inpustream, Ganzzahl len, Variable

Liest vom Stream len Zeichen, erzeugt einen String daraus, und speichert ihn in die Variable.

lese-Byte Inputstream, Variable

Liest ein einzelnes Byte vom Stream und speichert den Wert als Ganzzahl in die Variable.

EOF

Konstante für den Byte-Wert, der End-Of-Stream signalisiert.

stdout

stderr

stdin

Die Stream-Werte für Standardausgabe, Standarderror und Standardeingabe.

newline

Konstanter String-Wert, der bei Textausgaben wie mit gib-aus als Zeilenende verwendet werden kann.

B.6 Side-Effects

Eingebaute Definitionen für Arbeit mit Side-Effect-Werten:

Sequenz(Side-Effect, ...)

Erzeugt einen neuen Side-Effect als Hintereinanderausführung der Argumentwerte. Im Vergleich zur Action-Sequenz (See section Actions und Side-Effects) ist dieser Wert nicht vom Kontext abhängig und kann so z. B. als Rückgabewert verwendet werden, seine Argumente sind jedoch schon ausgewertet worden, weshalb es zu den beschriebenen Problemen mit Variablen und dergleichen kommt.

nichts

Konstanter Side-Effect, der bei der Ausführung einfach nichts tut.

C. GNU Free Documentation License

		GNU Free Documentation License
		  Version 1.2, November 2002


 Copyright (C) 2000,2001,2002  Free Software Foundation, Inc.
     51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.


0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other
functional and useful document "free" in the sense of freedom: to
assure everyone the effective freedom to copy and redistribute it,
with or without modifying it, either commercially or noncommercially.
Secondarily, this License preserves for the author and publisher a way
to get credit for their work, while not being considered responsible
for modifications made by others.

This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense.  It
complements the GNU General Public License, which is a copyleft
license designed for free software.

We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does.  But this License is not limited to software manuals;
it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book.  We recommend this License
principally for works whose purpose is instruction or reference.


1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that
contains a notice placed by the copyright holder saying it can be
distributed under the terms of this License.  Such a notice grants a
world-wide, royalty-free license, unlimited in duration, to use that
work under the conditions stated herein.  The "Document", below,
refers to any such manual or work.  Any member of the public is a
licensee, and is addressed as "you".  You accept the license if you
copy, modify or distribute the work in a way requiring permission
under copyright law.

A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall subject
(or to related matters) and contains nothing that could fall directly
within that overall subject.  (Thus, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any
mathematics.)  The relationship could be a matter of historical
connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding
them.

The "Invariant Sections" are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License.  If a
section does not fit the above definition of Secondary then it is not
allowed to be designated as Invariant.  The Document may contain zero
Invariant Sections.  If the Document does not identify any Invariant
Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
the Document is released under this License.  A Front-Cover Text may
be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, that is suitable for revising the document
straightforwardly with generic text editors or (for images composed of
pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input
to text formatters.  A copy made in an otherwise Transparent file
format whose markup, or absence of markup, has been arranged to thwart
or discourage subsequent modification by readers is not Transparent.
An image format is not Transparent if used for any substantial amount
of text.  A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format, SGML
or XML using a publicly available DTD, and standard-conforming simple
HTML, PostScript or PDF designed for human modification.  Examples of
transparent image formats include PNG, XCF and JPG.  Opaque formats
include proprietary formats that can be read and edited only by
proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the
machine-generated HTML, PostScript or PDF produced by some word
processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page.  For works in
formats which do not have any title page as such, "Title Page" means
the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.

A section "Entitled XYZ" means a named subunit of the Document whose
title either is precisely XYZ or contains XYZ in parentheses following
text that translates XYZ in another language.  (Here XYZ stands for a
specific section name mentioned below, such as "Acknowledgements",
"Dedications", "Endorsements", or "History".)  To "Preserve the Title"
of such a section when you modify the Document means that it remains a
section "Entitled XYZ" according to this definition.

The Document may include Warranty Disclaimers next to the notice which
states that this License applies to the Document.  These Warranty
Disclaimers are considered to be included by reference in this
License, but only as regards disclaiming warranties: any other
implication that these Warranty Disclaimers may have is void and has
no effect on the meaning of this License.


2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License.  You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute.  However, you may accept
compensation in exchange for copies.  If you distribute a large enough
number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and
you may publicly display copies.


3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have
printed covers) of the Document, numbering more than 100, and the
Document's license notice requires Cover Texts, you must enclose the
copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
the back cover.  Both covers must also clearly and legibly identify
you as the publisher of these copies.  The front cover must present
the full title with all words of the title equally prominent and
visible.  You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve
the title of the Document and satisfy these conditions, can be treated
as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.

If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a computer-network location from which the general network-using
public has access to download using public-standard network protocols
a complete Transparent copy of the Document, free of added material.
If you use the latter option, you must take reasonably prudent steps,
when you begin distribution of Opaque copies in quantity, to ensure
that this Transparent copy will remain thus accessible at the stated
location until at least one year after the last time you distribute an
Opaque copy (directly or through your agents or retailers) of that
edition to the public.

It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give
them a chance to provide you with an updated version of the Document.


4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy
of it.  In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct
   from that of the Document, and from those of previous versions
   (which should, if there were any, be listed in the History section
   of the Document).  You may use the same title as a previous version
   if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
   responsible for authorship of the modifications in the Modified
   Version, together with at least five of the principal authors of the
   Document (all of its principal authors, if it has fewer than five),
   unless they release you from this requirement.
C. State on the Title page the name of the publisher of the
   Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications
   adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice
   giving the public permission to use the Modified Version under the
   terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections
   and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled "History", Preserve its Title, and add
   to it an item stating at least the title, year, new authors, and
   publisher of the Modified Version as given on the Title Page.  If
   there is no section Entitled "History" in the Document, create one
   stating the title, year, authors, and publisher of the Document as
   given on its Title Page, then add an item describing the Modified
   Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for
   public access to a Transparent copy of the Document, and likewise
   the network locations given in the Document for previous versions
   it was based on.  These may be placed in the "History" section.
   You may omit a network location for a work that was published at
   least four years before the Document itself, or if the original
   publisher of the version it refers to gives permission.
K. For any section Entitled "Acknowledgements" or "Dedications",
   Preserve the Title of the section, and preserve in the section all
   the substance and tone of each of the contributor acknowledgements
   and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document,
   unaltered in their text and in their titles.  Section numbers
   or the equivalent are not considered part of the section titles.
M. Delete any section Entitled "Endorsements".  Such a section
   may not be included in the Modified Version.
N. Do not retitle any existing section to be Entitled "Endorsements"
   or to conflict in title with any Invariant Section.
O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant.  To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.

You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list
of Cover Texts in the Modified Version.  Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity.  If the Document already
includes a cover text for the same cover, previously added by you or
by arrangement made by the same entity you are acting on behalf of,
you may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or
imply endorsement of any Modified Version.


5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified
versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its
license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy.  If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique number.
Make the same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History"
in the various original documents, forming one section Entitled
"History"; likewise combine any sections Entitled "Acknowledgements",
and any sections Entitled "Dedications".  You must delete all sections
Entitled "Endorsements".


6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in
the collection, provided that you follow the rules of this License for
verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this
License into the extracted document, and follow this License in all
other respects regarding verbatim copying of that document.


7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, is called an "aggregate" if the copyright
resulting from the compilation is not used to limit the legal rights
of the compilation's users beyond what the individual works permit.
When the Document is included in an aggregate, this License does not
apply to the other works in the aggregate which are not themselves
derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one half of
the entire aggregate, the Document's Cover Texts may be placed on
covers that bracket the Document within the aggregate, or the
electronic equivalent of covers if the Document is in electronic form.
Otherwise they must appear on printed covers that bracket the whole
aggregate.


8. TRANSLATION

Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections.  You may include a
translation of this License, and all the license notices in the
Document, and any Warranty Disclaimers, provided that you also include
the original English version of this License and the original versions
of those notices and disclaimers.  In case of a disagreement between
the translation and the original version of this License or a notice
or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements",
"Dedications", or "History", the requirement (section 4) to Preserve
its Title (section 1) will typically require changing the actual
title.


9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License.  Any other attempt to
copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License.  However,
parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such
parties remain in full compliance.


10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions
of the GNU Free Documentation License from time to time.  Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.  See
http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number.
If the Document specifies that a particular numbered version of this
License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or
of any later version that has been published (not as a draft) by the
Free Software Foundation.  If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.


ADDENDUM: How to use this License for your documents

To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and
license notices just after the title page:

    Copyright (c)  YEAR  YOUR NAME.
    Permission is granted to copy, distribute and/or modify this document
    under the terms of the GNU Free Documentation License, Version 1.2
    or any later version published by the Free Software Foundation;
    with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
    A copy of the license is included in the section entitled "GNU
    Free Documentation License".

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
replace the "with...Texts." line with this:

    with the Invariant Sections being LIST THEIR TITLES, with the
    Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.

If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License,
to permit their use in free software.

Inhaltsverzeichnis

Über dieses Dokument

Dieses Dokument wurde erzeugt von Daniel Kraft am 23. Juli 2012 durch texi2html 1.82.

Die Links in der Navigationsleiste haben die folgende Bedeutung:

wobei das Beispiel annimmt, dass die aktuelle Position bei Unterabschnitt 1-2-3 in einem Dokument mit folgender Struktur liegt:

• 1. Abschnitt 1
  • 1.1 Unterabschnitt 1-1
    • ...
  • 1.2 Unterabschnitt 1-2
    • 1.2.1 Unterabschnitt 1-2-1
    • 1.2.2 Unterabschnitt 1-2-2
    • 1.2.3 Unterabschnitt 1-2-3     <== Aktuelle Position
    • 1.2.4 Unterabschnitt 1-2-4
  • 1.3 Unterabschnitt 1-3
    • ...
  • 1.4 Unterabschnitt 1-4

Dieses Dokument wurde erzeugt von Daniel Kraft am 23. Juli 2012 durch texi2html 1.82.