\chapter{Umgebung der Tycoon Modulverwaltung}
\label{cha_umgebung}

In diesem Kapitel wird gekl"art werden, in welcher Beziehung die im
vorangegangenen Kapitel erl"auterten Objekte der Modulverwaltung zu
anderen Komponenten des Tycoon Systems stehen.  Hier soll deutlich
werden, in welchem Kontext die Modulverwaltung arbeitet.  Im
Gegensatz zu anderen Systemen handelt es sich bei Tycoon um ein
persistentes Objektsystem.  Dies impliziert z.~B.\ die Benutzung eines
Objektspeichers.  Au"serdem kann das Tycoon System "uber den Toplevel
auf eine interaktive Weise benutzt werden.  Die Aufgaben, die
diesen Komponenten im Zusammenhang mit der Modulverwaltung zukommen,
werden im folgenden betrachtet.  Sie zeigen den Kontext auf, in dem
die Modulverwaltung arbeitet.  Die hier vorgestellte Umgebung bildet
somit die Grundlage f"ur die weitere Analyse.

Zu jedem Modul, jeder Schnittstelle und jeder Bibliothek\footnote{F"ur
eine Bibliothek existieren nicht alle der aufgef"uhrten
Repr"asentationen, sondern von der vorliegenden Liste nur die ersten
beiden.}, jedem Objekt der Modulverwaltung also, existieren
unterschiedliche Repr"asentationen, wie z.~B.:

\begin{itemize}
\item der Quelltext
\item der "ubersetzte Quelltext
\item der abstrakte \tl Syntaxbaum
\item der abstrakte TML Syntaxbaum
\item der Bytecode
\item evtl. C-Code\footnote{Der Tycoon Compiler erzeugt aus dem \tl -Code
in mehreren Schritten Bytecode, der anschlie"send von der Tycoon
Maschine interpretiert wird.  Normalerweise erfolgt keine "Ubersetzung
in C-Code und danach von einem C-Compiler in Maschinencode.  Es gibt
jedoch durchaus die M"oglichkeit, auch C-Code zu generieren und damit
Verbesserungen im Laufzeitverhalten zu erreichen.}
\end{itemize}

Diese Repr"asentationen sind insofern interessant, als da"s sie an
unterschiedlichen Lokationen abgelegt werden und es Werkzeuge geben
mu"s, die Abbildungen zwischen den Repr"asentationen vornehmen
k"onnen.  In dieser Arbeit werden nur die Darstellung als Quelltext
und als "ubersetzter Quelltext n"aher betrachtet.  Abstrakter \tl 
und TML Syntaxbaum und der Bytecode werden vom Compiler erzeugt.
Der Bytecode schlie"slich wird von der Tycoon Maschine ausge\-f"uhrt.

\section{Objektspeicher}
\label{sec_objektspeicher}

Im Objektspeicher werden beliebig strukturierte \tl-Objekte abgelegt,
nachdem sie w"ah\-rend einer Tycoon-Sitzung erzeugt wurden.  Sie
k"onnen explizit persistent gemacht werden.  Eine
Freispeicherverwaltung ({\itshape garbage collection}) sorgt daf"ur,
da"s nicht mehr erreichbare Objekte automatisch aus dem Objektspeicher
entfernt werden.

Dauerhaft werden hier nur "ubersetzte Komponenten abgelegt.  Die
Speicherung des Quelltextes erfolgt nicht im Objektspeicher, obwohl
dies m"oglich w"are.  Der Grund hier\-f"ur liegt in der Tatsache, da"s
die zur Bearbeitung des Quelltextes im Objektspeicher n"oti\-gen
Werkzeuge zum Editieren, Drucken, Formatieren aber z.~B.\ auch zum
Suchen in mehreren Quelltexten zugleich etc.\ nicht oder nicht in
gen"ugender Qualit"at vorhanden sind.  Allgemein verf"ugbare
Werkzeuge, die die entsprechenden Aufgaben erf"ullen, sind zum Lesen
und Schreiben von Objekten stets an das Dateisystem gebunden und
k"onnen nicht auf den Objektspeicher zugreifen.

In der Praxis widerspricht ein weiterer Grund dem Ablegen von
Quelltexten im Objektspeicher.  Zum einen laufen die gegenw"artigen
Implementierungen noch nicht ausreichend stabil, um tats"achlich eine
Datensicherheit und damit Persistenz garantieren zu k"onnen.  H"aufige
Abst"urze w"urden dann jeweils zum Verlust der gesamten Quelltexte
f"uhren.  Zum anderen fehlt die M"oglichkeit, ein Backup eines
Objektspeichers anzulegen.  Dies k"onnte zu einem gewissen Teil den
ersten Nachteil wieder aufheben.  Bislang ist eine Datensicherung nur
dann m"oglich, wenn der Objektspeicher an das Dateisystem gebunden
ist.  In diesem Fall m"ussen jedoch externe Werkzeuge benutzt werden;
f"ur Implementierungen, die nicht an das Dateisystem gebunden sind,
gibt es keine Backup-M"oglichkeiten.

\section{Externer Speicher}

Neben dem Objektspeicher wird als persistenter Speicher auch das auf
der Rechnerarchitektur verf"ugbare Dateisystem genutzt.  Der
Objektspeicher ist je nach Implementation\footnote{Die derzeit am
h"aufigsten genutzten Objektspeicherimplementierungen {\itshape
tymem}\/ und {\itshape tysin}\/ nutzen entweder Dateien oder den
Hauptspeicher des Rechners, der bei {\itshape do saveSystem}\/ dann in
einer Datei gespeichert wird.} ebenfalls an das Dateisystem gebunden.

Das Tycoon System ist auf vielen Architekturen verf"ugbar.
Infolgedessen mu"s es mit den verschiedensten Dateisystemen
zusammenarbeiten und dennoch zum Rest des Systems eine definierte
Schnittstelle f"ur den Zugriff darauf bereitstellen, die in allen
Systemen G"ultigkeit hat.  Besonders die Beschr"ankung in der L"ange
von Dateinamen oder das Trennzeichen zwischen Komponenten eines
Pfadnamens k"onnen hier Probleme darstellen.

Es wurde bereits erl"autert, wie Moduln, Schnittstellen und
Bibliotheken in \tl und im Objektspeicher repr"asentiert werden.
Externer Speicher dient dazu, sowohl die Quell\-text\-re\-pr"a\-sen\-tation
als auch "ubersetzte Objekte abzulegen.  Die entsprechende
Verzeichnisstruktur wird durch die Umgebungsvariablen {\itshape
librarySourceDir}\/ und {\itshape libraryObjectDir}\/ 
festgelegt (s.~a.\ Tabelle~\ref{tab_dateien}).

\begin{table}[htb]
\centering
\begin{tabular}{|l|l|l|}
\hline

Art der Datei &Dateiname &Verzeichnis \\
\hline
Quelltext einer Bibliothek {\itshape lib} &
{\itshape lib}.tl &
{\itshape librarySourceDir/lib} \\

Quelltext eines Moduls {\itshape mod} aus {\itshape lib} &
{\itshape mod}.tm &
{\itshape librarySourceDir/lib} \\

Quelltext einer Schnittstelle {\itshape itf} aus {\itshape lib} &
{\itshape itf}.ti & 
{\itshape librarySourceDir/lib} \\

"Ubersetzte Bibliothek {\itshape lib} &
{\itshape lib}.tl.x &
{\itshape libraryObjectDir/lib} \\

"Ubersetztes Modul {\itshape mod} aus {\itshape lib} &
{\itshape mod}.tm.x &
{\itshape libraryObjectDir/lib} \\

"Ubersetzte Schnittstelle {\itshape itf} aus {\itshape lib} &
{\itshape itf}.ti.x &
{\itshape libraryObjectDir/lib} \\
\hline
\end{tabular}
\caption{Dateiarten mit ihrer Bedeutung und Lokation}
\label{tab_dateien}
\end{table}

\section{Fingerprint}
\label{sec_fingerprint}

In nahezu jedem Dateisystem werden die Dateien mit einem Zeitstempel
abgelegt, der die Zeit der letzten "Anderung\footnote{In vielen
Dateisystemen, die mit Unix Anwendung finden, werden zu jeder Datei
drei Zeitmarken festgehalten: \begin{itemize}\item die Zeit der
letzten Ver"anderung \item die Zeit der letzten Status"anderung \item
die Zeit des letzten Zugriffs \end{itemize} In diesem Zusammenhang ist
die erste der genannten Zeiten die ausschlaggebende.} festh"alt.
Diese Zeitmarke ist wichtig, um festzustellen, ob die "ubersetzte
Datei und der Quelltext noch konsistent sind.  Weist der Zeitstempel
des Quelltextes ein j"ungeres Datum auf als die Zeitmarke des
entsprechenden "ubersetzten Objektes, so kann man annehmen, da"s der
Quelltext nach der letzten "Ubersetzung ge"an\-dert wurde.  Es kann
allerdings in diesem Fall nicht notwendigerweise davon ausgegangen
werden, da"s beide Objekte inkonsistent sind.  Wurde z.~B.\ nur ein
Kommentar ge"an\-dert oder hinzugef"ugt, entspricht der "ubersetzte Text
immer noch seinem Quelltext.  Um diese Situationen zu erkennen und
daraus resultierende "Ubersetzungsvorg"ange zu vermeiden, enthalten
die "ubersetzten Einheiten des Tycoon Systems zus"atzlich eine
spezielle Pr"ufsumme ({\itshape Fingerprint}) des Quelltextes.  Soll
dann "uberpr"uft werden, ob ein Quelltext der "Ubersetzung bedarf,
wird neben der "ublichen Pr"ufung der Zeitstempel sein Fingerprint
berechnet.  Sind dieser und der bei der "ubersetzten Einheit
gespeicherte gleich, bedeutet das, da"s eine erneute "Ubersetzung
"uberfl"ussig ist.  Der Quelltext hat sich nicht signifikant
ge"andert.

Zur Berechnung dieser Pr"ufsumme werden nur f"ur die Sprache relevante
Teile des Quelltextes herangezogen.  Alle anderen Elemente eines
Quelltextes, wie z.~B.\ Kommentare oder Leerzeilen, werden f"ur die
Berechnung nicht betrachtet.

Durch den Fingerprint k"onnen zwar unn"otige "Ubersetzungsvorg"ange
vermieden werden, es steht ihm allerdings ein Nachteil gegen"uber.
Der Compiler verweist bei Fehlermeldungen auf das Auftreten der
relevanten Information mittels Zeilennummer und Spaltenangabe.  Diese
Information ist jedoch ung"ultig, wenn der Quelltext sich ge"andert,
der "ubersetzte Text aber unver"andert geblieben ist.

\section{Toplevel}
\label{sec_toplevel}

Der Zugang zum Tycoon System erfolgt f"ur den Benutzer "ublicherweise
"uber den interaktiven Toplevel.  Vergleichbar mit der Eingabezeile
eines Kommandozeileninterpreters in UNIX kann der Benutzer Befehle an
das Tycoon System absetzen und erh"alt Ergebnisse, Warnungen,
Fehlermeldungen etc.\ zur"uck.  Der Toplevel ist die
Benutzerschnittstelle\footnote{In \cite{tycoon_po} wird auch auf eine
fensterorientierte Benutzerschnittstelle hingewiesen.  Abh"angig vom
verwendeten Betriebsystem kann die Benutzerschnittstelle
unterschiedliche Gestalt annehmen.  Die interaktive Arbeitsweise am
Toplevel ist aber auf jeden Fall m"oglich.} des Tycoon Systems.

Alle T"atigkeiten, die der Benutzer ausf"uhren m"ochte, startet er
durch Kommandos auf dem Toplevel, die dann in einer zyklisch
durchlaufenen Schleife abgearbeitet werden ({\itshape top level
loop}).  Zu diesen Kommandos geh"ort z.~B.\ das Setzen von
Systemparametern aber auch die f"ur die Modulverwaltung wichtigen
T"atigkeiten des "Ubersetzen, Binden und Ausf"uhren.  Bei der
standardm"a"sig verwendeten Grammatik werden alle diese Kommandos
durch das Wort {\itshape do}\/ eingeleitet, gefolgt von dem
entsprechenden Befehl mit seinen Argumenten.  Eine genaue Beschreibung
der f"ur die Modulverwaltung relevanten Toplevel-Kommandos wird in
Kapitel~\ref{cha_semantik} gegeben.\footnote{Eine vollst"andige Liste
aller Toplevel-Kommandos mit einer kurzen Beschreibung erh"alt man
durch Eingabe von {\itshape do help;}.}

Neben der M"oglichkeit direkt Befehle abzusetzen, k"onnen auch
Skripten benutzt werden.  Diese werden dann durch Eingabe von

\begin{quote}
\begin{alltt}
do "Pfadname" 
\end{alltt}
\end{quote}

\noindent
abgearbeitet.

Au"ser den erw"ahnten Kommandos kann der Benutzer auf dem Toplevel
auch beliebig strukturierte \tl -Terme eingeben.  Insbesondere hat er
die M"oglichkeit, Werte an Namen zu binden.  Diese Namen sind dann auf
dem Toplevel sichtbar, man spricht auch von Toplevel-Bindungen.  Auch
Moduln und Schnittstellen k"onnen auf diese Weise an Namen, den Modul-
bzw.\ Schnittstellennamen, gebunden werden und sind dann auf dem
Toplevel sichtbar.  Im Unterschied zu anderen Bindungen, werden diese
meist durch das spezielle Konstrukt {\itshape import}\/ angelegt
(s. Abschnitt~\ref{sec_import}).  Auf diese Weise definierte Moduln
und Schnittstellen befinden sich nach Abschnitt~\ref{sec_zustand} im
Zustand {\itshape definiert}.  An dieser Stelle wird auf die etwas
verwirrende Begriffsbildung hingewiesen.  \tl-Objekte k"onnen an Namen
{\itshape gebunden}\/ werden und sind dann {\itshape definiert}.  Im
Zusammenhang mit Moduln versteht man unter {\itshape Binden}\/ (vom
englischen {\itshape link}) den Vorgang, Referenzen auf externe
Objekte aufzul"osen.

Es ist auch denkbar, Moduln und Schnittstellen auf dem Toplevel direkt
einzugeben.  Dabei ist jedoch zu bedenken, da"s es dann keine
korrespondierende Dateien gibt.  Auch ist aus den in
Abschnitt~\ref{sec_objektspeicher} genannten Gr"unden eine Bearbeitung
schwierig.

\section{Wurzelbibliothek}
\label{sec_wurzelbibliothek}

Innerhalb einer interaktiven Sitzung, in der der Benutzer Phrasen auf
dem Toplevel eingeben kann, gibt es stets eine ausgezeichnete
Bibliothek, die die Sichtbarkeitsbereiche aller importierten
Bezeichner festlegt, die {\itshape Wurzelbibliothek}.  Sie weist die
in Abschnitt \ref{sec_bibliothek} genannten Merkmale auf.
