\chapter{Semantik der Toplevel-Kommandos}
\label{cha_semantik}

Ein Teil der im vorangegangenen Kapitel beschriebenen Aufgaben einer
Modulverwaltung werden im Tycoon System durch Toplevel-Kommandos
implementiert (s.~Abschnitt \ref{sec_toplevel}).  Da sich die
verf"ugbare Dokumentation haupts"achlich auf Anwendung, nicht aber auf
die Semantik dieser Kommandos konzentriert, soll dies an dieser Stelle
nachgeholt werden.

Der Beschreibung der Semantik der Toplevel-Kommandos, die der
{\itshape Modulverwaltung}\/ zugerechnet werden k"onnen, wurden im
wesentlichen vier Fragen zugrundegelegt.

\begin{itemize} 

\item [1.] 
Welche Objekte sind betroffen?  Werden z.~B.\ Bibliotheken, Moduln
oder Schnittstellen durch das Kommando ber"uhrt, und in welchen
Beziehungen stehen diese zueinander?

\item [2.] 
Was geschieht mit den Objekten?  Konkret also, welche Operationen
werden auf diesen oder mit diesen durchgef"uhrt?  Entstehen weitere
Objekte, wie werden sie benannt und wo werden sie abgelegt?  In
welcher Reihenfolge werden die Objekte bearbeitet?

\item [3.] 
Unter welchen Voraussetzungen werden Aktionen durchgef"uhrt?  Die
"Ubersetzung eines Moduls mu"s z.~B.\ nur in bestimmten F"allen
angesto"sen werden.  Welche Bedingungen m"ussen erf"ullt sein und,
welche Daten werden zur "Uberpr"ufung dieser Bedingungen herangezogen?

\item [4.] 
Was geschieht im Falle eines Fehlers?  Werden einige Aktionen dennoch
durchge\-f"uhrt?  Wird das Kommando nach dem ersten Fehler abgebrochen
oder erfolgt eine weitere Bearbeitung?

\end{itemize}

Vor der Beschreibung der einzelnen Kommandos sei noch einmal auf die
Begriffskl"arung von Abschnitt~\ref{sec_zustand} verwiesen.  Eine
Komponente kann sich, je nach Kommando, das auf sie angewendet wurde
bzw.\ noch nicht angewendet wurde, in verschiedenen Zust"anden
befinden.

\section {import {\it components}}
\label{sec_import}

Mit {\itshape import components}\/ k"onnen ein oder mehrere Moduln
oder Schnittstellen in den Objektspeicher geladen und entsprechend
Toplevel-Bindungen definiert werden.  Bei {\itshape components}\/
handelt es sich um eine Liste, die sowohl Modul- als auch
Schnittstel\-len-Bezeich\-ner enthalten kann.  Die Komponenten werden
der Reihe nach von links nach rechts abgearbeitet.  Voraussetzung f"ur
das erfolgreiche Importieren ist das Vorhandensein des ausf"uhrbaren
Codes aller auch transitiv erreichbaren Komponenten.  Au"serdem
m"ussen sich alle Komponenten im Sichtbarkeitsbereich der
aktuellen Wurzelbibliothek befinden.

Handelt es sich bei einer Komponente um ein Modul, so wird zuerst die
zugeh"orige Schnittstelle importiert und dessen ausf"uhrbarer Code
geladen (im folgenden wird nicht explizit auf den ausf"uhrbaren Code
Bezug genommen, dieser ist aber immer gemeint, wenn es darum geht,
da"s Komponenten geladen bzw.\ gebunden werden etc.).  Folgende
Eingaben f"uhren daher zu denselben Bindungen in exakt derselben
Ausf"uhrungsreihen\-folge:

\begin{quote}
\begin{alltt}
import ascii;         
import :Ascii ascii;  
import ascii :Ascii;  
\end{alltt}
\end{quote}

Die Schnittstelle wird im ersten Fall aus der aktuellen
Wurzelbiblio\-thek bestimmt.  Auch im dritten Fall wird zun"achst die
Schnittstelle {\itshape Ascii}\/ importiert; das explizit genannte
{\itshape :Ascii}\/ hat also keine Wirkung, da es sich zu diesem
Zeitpunkt bereits im Objektspeicher befindet.  Nur der zweite Fall
entspricht also genau der Reihenfolge, in der auch die Modulverwaltung
des Tycoon-Compiler die Bearbeitung vornimmt.

Enthalten ein Modul oder eine Schnittstelle in der {\itshape
import}-Klausel weitere Moduln oder Schnittstellen, so werden
zun"achst diese geladen und Moduln bzw.\ deren evaluierter Tupelwert
gebunden.  Dieser Vorgang geschieht in einer rekursiven Weise, so da"s
ein Modul erst dann gebunden wird, wenn bereits alle Komponenten, von
denen es abh"angig ist, geladen und evtl.\ gebunden sind.  Da ein
Modul von seiner Schnittstelle implizit ab\-h"angig ist, m"ussen auch,
wie oben beschrieben, zun"achst die Schnittstelle und dann das Modul
importiert werden.

\begin{sloppypar}
Ist der Lade- und Bindevorgang f"ur alle betroffenen Komponenten
abgeschlossen, werden Toplevel-Bindungen definiert.  Dies geschieht
f"ur alle explizit in {\itshape components}\/ angegebenen Moduln und
(explizit oder implizit angegebenen) Schnittstellen und f"ur alle
Komponenten, die durch diese Schnittstellen sichtbar geworden sind.  
\end{sloppypar}

Befindet sich eine Komponente, die durch den oben beschriebenen
Vorgang direkt oder indirekt betroffen ist, bereits im Objektspeicher,
so wird diese nicht ein weiteres Mal geladen oder gebunden.  Auch eine
"Uberpr"ufung, ob der "ubersetzte Code der Datei aktueller als der im
Objektspeicher ist, findet nicht statt, sondern mu"s explizit
durchgef"uhrt werden, z.~B.\ durch das neu eingef"uhrte Kommando
{\itshape do snycComponent} (s.~Abschnitt~\ref{sec_sync}).


\section {do makeComponent {\itshape component}}

\label{do_makeComponent}
\begin{sloppypar}
Dieses Kommando bewirkt die "Ubersetzung des Quellcodes von {\itshape
component}\/ und aller Schnittstellen, die transitiv von {\itshape
component}\/ erreichbar sind.  Eine "Ubersetzung findet dabei nur
statt, wenn mindestens eine der folgenden Bedingungen erf"ullt ist: 
\end{sloppypar}

\begin {itemize}

\item 
Es existiert bisher noch kein "ubersetzter Code.

\item 
Der Quellcode wurde seit der letzten "Ubersetzung signifikant
ge"andert, d.~h.\ der Fingerprint des Quellcodes und des "ubersetzten
Codes sind unterschiedlich.

\item 
Eine oder mehrere von {\itshape component}\/ importierte
Schnittstellen wurden seit der letzten "Ubersetzung ebenfalls
"ubersetzt.

\end {itemize}

Die Reihenfolge der "Ubersetzung wird dadurch festgelegt, da"s zuerst
versucht wird, alle importierten Komponenten zu "ubersetzen.

Weiterhin mu"s sich {\itshape component}\/ im Sichtbarkeitsbereich der
Wurzelbibliothek befinden.  Unter der Annahme, da"s sich {\itshape
component}\/ in der Bibliothek {\itshape library}\/ befindet, erwartet
der Compiler den Quellcode im Verzeichnis {\itshape
librarySourceDir/library}\/ und legt den "ubersetzten Code in
{\itshape libraryObjectDir/library}\/ unter dem Namen {\itshape
component.tm.x}\/ im Falle eines Moduls und {\itshape
component.ti.x}\/ im Falle einer Schnittstelle ab.  {\itshape
librarySourceDir}\/ und {\itshape libraryObjectDir}\/ sind dabei
Variable, die mit {\itshape do set}\/ entsprechend gesetzt werden
k"onnen.

Ist bei der "Ubersetzung einer der betroffenen Komponenten ein Fehler
aufgetreten, so wird der gesamte "Ubersetzungsvorgang abgebrochen und
eine entsprechende Meldung ausgegeben.


\section {do make {\itshape component}}

Im Gegensatz zu {\itshape do makeComponent}\/ betrifft dieses Kommando
sowohl Schnittstellen als auch Moduln.  Es werden also zus"atzlich
alle von {\itshape component}\/ transitiv importierten Moduln geladen
und ggf.\ "ubersetzt.  Anschlie"send ist {\itshape component}\/
importierbar, d.~h. in diesem Fall wird die Komponente gebunden und
auf dem Toplevel definiert, da {\itshape component}\/ selbst und alle
transitiv erreichbaren Komponenten bereits beim "Ubersetzungsvorgang
geladen wurden.


\section {do makeLibraries {\itshape component}}

\label{do_makeLibraries}
Eine Bibliothek legt f"ur die enthaltenen Moduln und Schnittstellen
den Sichtbarkeitsbereich fest.  Eine entsprechende Beschreibung wird
vom Compiler durch {\itshape do makeLibraries}\/ erzeugt.  Die "Ubersetzung
einer Bibliothek erfolgt nur, wenn eine oder mehrere der folgenden
Bedingungen erf"ullt sind:

\begin {itemize}
\item 
Bisher existiert keine "ubersetzte Bibliothek.  Nur Quelltext wurde
bisher erstellt.

\item 
Es existiert keine Quelldatei der Bibliothek.  Dieser Fall tritt dann
auf, wenn die Bibliothek direkt auf dem Toplevel eingegeben wird ohne,
da"s eine Datei existiert.

\item 
Der Fingerprint der Quelldatei und der Objektdatei sind
unterschiedlich.

\item 
Eine in der Bibliothek {\itshape lib1}\/ enthaltene Bibliothek
{\itshape lib2}\/ wurde nach der letzten "Uber\-setzung von {\itshape
lib1}\/ neu "ubersetzt.
\end {itemize}

Nach erfolgreicher "Ubersetzung einer Bibliothek wird diese zur
aktuellen Wurzelbibliothek.  Alle Bezeichner, die bereits gebunden
wurden, bleiben dabei erhalten, auch wenn sie nicht im
Sichtbarkeitsbereich der neuen Bibliothek liegen.  Enth"alt eine
Bibliothek weitere Bibliotheken, so diese werden zun"achst "ubersetzt.


\section {do updateRootLibrary {\itshape component}}

Dieses Kommando l"adt die "ubersetzte Beschreibung der Bibliothek
{\itshape component}\/ und ersetzt damit die der Wurzelbibliothek.
Es setzt voraus, da"s sich die "ubersetzte Bibliothek im Verzeichnis
{\itshape libraryObjectDir/component}\/ unter dem Namen {\itshape
component.tl.x}\/ befindet.  Ist dies nicht der Fall, so wird die
Ausf"uhrung mit einem entsprechenden Fehlerhinweis abgebrochen.


\section {do loadComponent {\itshape component}}

Mit diesem Kommando ist es m"oglich, bereits im Objektspeicher
befindliche Komponenten zu aktualisieren oder neue Komponenten zu
laden, soweit sich diese im Sichtbarkeitsbereich der Wurzelbibliothek
befinden.  Au"serdem mu"s die Version der Komponente im Dateisystem
aktueller als die des Objektspeichers sein.  Abh"angig von {\itshape
component}\/ werden folgende F"alle unterschieden:

\begin {itemize}

\item 
Bei einem Modul erfolgt keine erneute Evaluation des Modulwertes.  Die
alte Version bleibt nach wie vor gebunden.

\item 
Im Falle einer Schnittstelle bleibt die Typinformation der alten
Schnittstelle erhalten.

\item 
Ist das Argument von {\itshape do loadComponent} eine Bibliothek, so
werden alle transitiv erreichbaren Komponenten gelesen.

\end {itemize}

Konnte eine Komponente nicht geladen werden, so wird ein
entsprechender Hinweis ausgegeben und evtl.\ mit dem Laden anderer
Komponenten fortgefahren.  Die alte Version bleibt unver"andert im
Objektspeicher.  

\section {do link {\itshape component}}

Die Semantik dieses Kommandos ist dem von {\itshape import}\/ sehr
"ahnlich: Die Komponente {\itshape component}\/ wird in den
Objektspeicher gelesen, und im Falle eines Moduls wird der Modulrumpf
evaluiert.  Eine Komponente wird erst dann gebunden, wenn alle
transitiv erreichbaren Komponenten gebunden sind.  Es bestehen die
folgenden Unterschiede zu {\itshape import}:

\begin {itemize}

\item 
\begin{sloppypar}
Argument von {\itshape do link}\/ kann auch eine Bibliothek sein.  Es werden
dann alle auch transitiv in dieser Bibliothek und in eingeschlossenen
Bibliotheken enthaltenen Moduln und Schnittstellen gebunden.
\end{sloppypar}

\item 
F"ur kein Modul und keine Schnittstelle wird eine Bindung auf dem
Toplevel angelegt.

\end {itemize}


\section {do unlink {\itshape component}}

Es werden abh"angig von {\itshape component}\/ die folgenden F"alle
unterschieden:

\begin {description}

\item [Modul:] 
Die Komponente wird als {\itshape nicht gebunden}\/ markiert.  Folglich
kann diese Komponente ein weiteres Mal gebunden werden.  Unabh"angig
vom Binde-Status ist die Komponente weiterhin auf dem Toplevel
definiert.

\item [Bibliothek:] 
Alle von der Bibliothek aus transitiv erreichbaren Moduln werden als
{\itshape nicht gebunden}\/ markiert.

\end {description}

Im Zusammenspiel mit {\itshape do link}\/ kann so die erneute
Evaluierung des Modulrumpfes erreicht werden.  Dies ist insbesondere
dann sinnvoll, wenn die Modulinitialisierung Seiteneffekte aufweist.

\section{Bewertung} 

Die h"aufig benutzten Kommandos {\itshape import}, {\itshape do make},
{\itshape do makeComponent}\/ und {\itshape do makeLibraries} sind in
ihrer Semantik so gefa"st, da"s sie vom Benutzer intuitiv verwendet
werden k"onnen.  Dies trifft allerdings nicht auf doe Kommandos 
{\itshape do loadComponent}, {\itshape do link}\/ und {\itshape do 
unlink} zu.  Ihr praktischer Nutzen ist unklar.  So
ist es nicht sinnvoll, Komponenten explizit zu laden.  Dies wird auch
automatisch von {\itshape import}\/ erledigt.  Der Nutzen der
Kommandos {\itshape do link}\/ und {\itshape do unlink} ist insofern
eingeschr"ankt, als da"s das damit intendierte Neuberechnen des
Modulwertes nicht klar erkennbar ist.  Es w"are sinnvoller, auch um
m"ogliche Inkonsistenzen zu verhindern, diese T"atigkeit in einem
einzigen Kommando zusammenzufassen.  Abbildung~\ref{abb_uebergang} 
macht den Zusammenhang zwischen Toplevel-Kommando und den in 
Kapitel~\ref{cha_objekte} eingef"uhrten Zust"anden deutlich.  
Dabei ist insbesondere zu beachten, da"s das Kommando 
{\itshape do unlink}\/ in diese Darstellung nicht sinnvoll aufgenommen
werden kann, da es keinen klaren Zustands"ubergang markiert.

\medskip
\begin{figure}[htb]
\centering\mbox{\epsfig{file=uebergang.eps}} 
\caption{Zust"ande, in denen sich ein Modul bzw.\ Schnittstelle befinden kann
und Kommandos, die die Zustands"uberg"ange ausl"osen}
\label{abb_uebergang}
\end{figure}

