Damit lockert Modula an dieser Stelle sein Typstrenge etwas. Nehmen wir die zwei Felder a und b:

Transkript

1 Modula-Marzipan, Teil 2 In dieser Folge beschäftigen wir uns mit Parametern von Prozeduren und wie man es mit legalen Mitteln schafft, Variablen unterschiedlicher oder gar beliebiger Typen zu übergeben. Offene Felder Einen Parametertyp, der keine Angabe über seine Größe enthält kennen und benutzen Sie täglich. Es handelt sich um die "offenen Felder", die als Parametertyp zwar festlegen, welchen Typ die Feldelemente haben, aber nicht deren Anzahl. Damit lockert Modula an dieser Stelle sein Typstrenge etwas. Nehmen wir die zwei Felder a und b: TYPE ZehnInts = ARRAY [0..9] OF INTEGER; ElfInts = ARRAY [1..11] OF INTEGER; VAR a: ZehnInts; b: ElfInts; Nach den Regeln von Modula-2 haben a und b völlig unterschiedliche Typen. Bei dem Versuch einer Zuweisung a:=b vermerkt der Compiler Inkompatibilität, gerade so, als sollte einem CHAR ein LONGREAL zugewiesen werden. Eine Prozedur zu schreiben, die sowohl ein CHAR als auch ein LONGREAL als Parameter akzeptiert scheint aussichtslos zu sein, wie sollte man das in der Prozedur-Definition ausdrücken? Anders ist es im Fall der Felder; hier kennt Modula einen gesonderten Parameter-Typ. (Daß Prozeduren auch für wechselnde CHAR- und LONGREAL-Parameter möglich sind, werden Sie nach diesem Artikel übrigens wissen...) Die Deklaration eines offenen Feldes als Parameter entspricht der "normalen" Deklaration eines Felds, nur fällt die Angabe der Feldgröße weg. Nehmen wir zwei Köpfe von Prozeduren, die eine Summe des übergebenen INTEGER-Feldes errechnen sollen: PROCEDURE SumTen(p:ZehnInts):LONGINT;... PROCEDURE Sum(p:ARRAY OF INTEGER):LONGINT;... SumTen könnte nur a als Parameter akzeptieren. Sum hingegen macht keine Aussage über die Anzahl der geforderten Feldelemente. Sie kann damit alle Felder, die aus INTEGERs bestehen übernehmen, also sowohl a als auch b.

2 Es leuchtet ein, daß die Lösung mit den offenen Feldern variabler ist. Würden wir auf festen Feldgrößen bestehen, müßte eine Prozedur SumEleven hinzukommen, die speziell für die Feldgröße [1..11] geschrieben wäre. Gleichzeitig bedingen die offenen Felder einen Informationsverlust: Man weiß eben nicht mehr, wie groß das übergebene Feld ist. Der Compiler kann es nicht ermitteln, da die Prozeduraufrufe ja erst zur Laufzeit stattfinden. Also muß es eine Funktion geben, die man in Sum verwenden kann, um die Größe des übergebenen Felds zu ermitteln. Sie heißt HIGH, liefert ein ganzzahliges Resultat und kann nur auf offene Feldparameter angewandt werden. Es leuchtet ein, daß sie zur Laufzeit unterschiedliche Ergebnisse abliefert, nämlich die jeweilige Größe des aktuell übergebenen Felds. Sie sollten übrigens zu HIGH in Ihrem Compiler-Handbuch den Ergebnistyp nachschlagen. Eigentlich sollte die Funktion ein CARDINAL abliefert, was logisch ist, da ein Feld ja keine negative Größe haben kann. In SPC-Modula beispielsweise liefert HIGH allerdings ein INTEGER. Bevor wir nun aber die Prozedur ausformulieren können, taucht ein neues Problem auf: Wie laufen die Indizes? HIGH liefert <Anzahl der Feldelemente> -1, aber aufgrund des genannten Informationsverlusts weiß die Prozedur nicht, mit welchem Index das Feld beginnt. Um die Einführung einer weiteren Funktion zu vermeiden, gilt in Modula, daß offene Feldparameter immer mit dem Index 0 beginnen. Man erkennt hier auch, warum HIGH die <Anzahl der Feldelemente> - 1 liefert: Ein offenes Feld p hat die Indizes [0..HIGH(p)]. Nun kann Sum formuliert werden: PROCEDURE Sum(p:ARRAY OF INTEGER):LONGINT; VAR sum : LONGINT; index : INTEGER; sum:=0; FOR index:=0 TO HIGH(p) DO sum:=sum+p[i] RETURN sum END Sum; Die "Verschiebung" der Indizes sollte man beachten. Nehmen wir an, daß alle Elemente des Felds b mit 1 belegt sind. Nullify sei nun eine Prozedur, die ein Feldelement auf 0 setzt: PROCEDURE Nullify(VAR p:array OF INTEGER; i:integer);

3 p[i]:=0 END Nullify Rufen wir Nullify(a,5) auf, dann ist hinterher entsprechend unseren Erwartungen a[5]=0. Im Fall von Nullify(b,5) bleibt b[5]=1, b[4] hingegen wird aufgrund der Indexverschiebung auf 0 gesetzt. Der Grund ist klar: In Nullify hat b die Indizes [0..10], also trifft der Zugriff p[5] in das Element b[4]. Die oben angesprochene tägliche Benutzung von offenen Feldern findet sich übrigens bei den String-Routinen aus dem Standard-Modul Strings. Dort sind alle Parameter vom Typ ARRAY OF CHAR und können damit auf Zeichenfelder beliebiger Große angewandt werden. Eine Einschränkung muß allerdings genannt werden: Offene Felder gibt es nur für eine Dimension. Es gibt keine Möglichkeit, zwei- oder mehrdimensionale Felder in dieser Art zu verarbeiten. Zur Übung sollten Sie etwas mit offenen Feldern spielen und insbesondere die Auswirkung der Indexverschiebung erproben. Eine weitere nützliche Überlegung ist die Frage, warum die Zuweisung von Zeichenketten unterschiedlicher Feldgröße direkt nicht funktioniert, warum es mit Strings.Assign geht und wie diese Prozedur aussieht (Dabei müssen Sie berücksichtigen, daß der tatsächlich mit Zeichen belegt Teil des CHAR-Felds vom Null-Zeichen 0C abgeschlossen wird - außer wenn Ihr Compiler bei konstanten Zeichenketten dieses Null-Zeichen nicht automatisch erzeugt). BYTE, WORD und LONGWORD Eigentlich beim jedem Compiler vorhanden, aber dennoch systemabhängig, existieren im Pseudo-Modul SYSTEM die Typen BYTE, WORD und LONGWORD. WORD und BYTE gibt es auf jeden Fall, LONGWORD muß nicht unbedingt vorhanden sein. Die drei Typen haben die Eigenschaft, daß sie zu allen anderen Typen gleicher Speichergröße kompatibel sind. Gleichzeitig existieren für sie keinerlei Operatoren, man kann sie also beispielsweise nicht addieren. Ihre größte Wirkung entfalten sie als Parametertyp von Prozeduren. Schon in der letzten Folge sind Sie bei dem Modul BoolWordOps SYSTEM.WORD als Parameter- Typ begegnet. Die Prozeduren haben durch dessen Verwendung die angenehme Eigenschaft, daß sie als Parameter sowohl INTEGERs als auch CARDINALs akzeptieren, denn beide haben - normalerweise - genau die gleiche Speichergröße wie WORD. Ein WORD benötigt üblicherweise 16 Bit. BYTE belegt - wie der Name fast schon sagt - acht Bit. Verwendet man BYTE als

4 Parametertyp, kann man CHARs übergeben und auch BOOLEANs, wenn sie mit 8 Bit implementiert sind. LONGWORD schließlich hat eine Größe von 4 Bytes. Damit ist es kompatibel zu LONGCARD und LONGREAL. Sind REALs mit einfacher Genauigkeit implementiert, belegen auch sie vier Bytes. Übrigens gibt es für Variablen, die acht Bytes belegen - dies sind doppeltgenaue LONGREALs - keinen kompatiblen Typ aus SYSTEM (etwa VERYLONGWORD). Unter der Annahme, daß BITSETs mit WORD-Größe implementiert sind, könnte man nun beispielsweise eine Prozedur schreiben, die den übergebenen Parameter in Dual-Schreibweise ausgibt: IMPORT InOut; FROM SYSTEM IMPORT WORD, VAL;... PROCEDURE WriteHex(p:WORD); VAR bit:cardinal; FOR bit:=15 TO 0 BY -1 DO IF bit IN VAL(BITSET,p) THEN InOut.Write('1') ELSE InOut.Write('0') END END END WriteHex; Die kompatiblen Typen BYTE, WORD und LONGWORD führen in gewissem Sinne einen impliziten Typtransfer durch. Ein WriteHex ließe sich durchaus auch mit einem Prozedurkopf PROCEDURE WriteHex(p:CARDINAL); formulieren. Der Typtransfer in WriteHex mit VAL könnte dabei bestehen bleiben. Man müßte aber einen zusätzlichen Typtransfer beim Prozeduraufruf einfügen, so daß beispielsweise für die Hexausgabe einer INTEGER-Variablen i der Aufruf WriteHex(VAL(CARDINAL,i)) heißen würde. Bei der Verwendung von WORD kann dieses VAL wegfallen, da der Typtransfer implizit geschieht. Man sieht leicht, daß ein Aufruf WriteHex(i) eindeutig besser lesbar ist und der Programmierer auch nicht mehr sonderlich viel über den Parametertypen von WriteHex berücksichtigen muß. ARRAY OF BYTE Mit diesen Typen sind nun also die strengen Typregeln bei Parametern etwas gelockert, übrig bleibt allerdings noch die Festlegung der Speichergröße des

5 Parameters. Um diese Schranke zu brechen, kombiniert man einfach die beiden bisher behandelten Konzepte. Offene Felder heben die Größenfestlegung auf, die kompatiblen Typen die Typfestlegung. In der Kombination ist beides aufgehoben. Wir wollen einen Parameter beliebiger Größe zulassen; anders ausgedrückt, soll der Parameter einfach aus einer Reihe von Bytes bestehen. Und damit liegt fest, welcher Parameter-Typ dafür geeignet ist, ein offenes Feld aus Bytes - im Programm als ARRAY OF BYTE notiert. Und um diesen Effekt auszuprobieren, soll eine kleine Prozedur die Auswirkung des Mechanismus protokollieren: PROCEDURE Test(p:ARRAY OF BYTE); InOut.WriteCard(HIGH(p)+1,5); (* oder InOut.WriteInt!! *) InOut.WriteString(' Bytes übergeben'); InOut.WriteLn; FOR i:=0 TO HIGH(p) DO InOut.WriteHex(VAL(CARDINAL,p[i]),3) InOut.WriteLn END Test; Sie sollten nun ein Programm schreiben, und sich davon überzeugen, daß man tatsächlich jeden beliebigen Typ übergeben kann. Test demonstriert auch, wie man auf den Parameter zugreift. Eine Anwendung wäre nun eine Prozedur WriteCardVal, die einen beliebigen ganzzahligen Parameter akzeptiert und unter Berücksichtigung dessen Größe versucht, ihn korrekt auszugeben. Die Idee dabei ist, die Größe des Parameters geeignet mit den Größen der Standardtypen für Ganzzahlen zu vergleichen. Sind beispielsweise CARDINALs mit 2 Byte implementiert und werden 2 Byte als Parameter übergeben, dann soll die Ausgabe mit WriteInt und WriteCard geschehen; bei 4 Byte nehmen wir LONGCARD und LONGINT an und geben mit WriteLongint und WriteLongcard aus. Die Ausgabe von jeweils zwei Werten ergibt sich übrigens aus der Tatsache, daß es nicht möglich ist, aus den Bitmustern von CARDINALs und INTEGERs herauszufinden, ob ein Vorzeichen vorhanden ist oder nicht. PROCEDURE WriteCardVal(v:ARRAY OF BYTE);

6 VAR word : ARRAY [0..1] OF BYTE; (* TSIZE(CARDINAL)=2! *) long : ARRAY [0..3] OF BYTE; (* TSIZE(LONGCARD)=4! *) i : INTEGER; IF HIGH(v)+1=TSIZE(CARDINAL) THEN word[0]:=v[0]; word[1]:=v[1]; InOut.WriteInt(VAL(INTEGER,word),6); InOut.Write('/'); InOut.WriteCard(VAL(CARDINAL,word),5); ELSIF HIGH(v)+1=TSIZE(LONGCARD) THEN FOR i:=0 TO 3 DO long[i]:=v[i] InOut.WriteLongint(VAL(LONGINT,long),11); InOut.Write('/'); InOut.WriteLongcard(VAL(LONGCARD,long),10); END WriteCardVal; Die Standardfunktion TSIZE muß bei einigen Systemen aus SYSTEM importiert werden. Auch könnten die Ausgaberoutine für LONGCARD und LONGINT eine andere Groß- und Kleinschreibung aufweisen - Sie müssen WriteCardVal also noch anpassen. Das Umkopieren des Parameters in die Felder word und long ist nötig, damit VAL arbeiten kann. Einen Typtransfer auf ein offenes Feld lehnt der Compiler ab, dies ist logisch, da er die Größe des Feldes nicht kennen kann. Die Prozedur ist auch keineswegs vollständig und kann natürlich korrekte Ausgaben nicht immer garantieren, denken Sie nur an die Übergabe eines RECORDs mit der Speichergröße 4 Byte. Die Ausgabe ist dann natürlich falsch. WriteCardVal soll als kleine Anregung zu eigenen Experimenten dienen. Schreiben Sie doch eine Prozedur WriteRealVal, mit der sowohl REALs als auch LONGREALs ausgegeben werden können! Einer Einschränkung des Mechanismus werden sie sehr bald begegnen: Man kann keine Konstanten für ein ARRAY OF BYTE übergeben. Zumindest nicht auf den meisten Systemen, die für den ST erhältlich sind. Sowohl die ETH-Systeme, als auch Megamax weisen den Versuch mit einem Hinweis auf eine "Implementation Restriction" ab. Diese Einschränkung ist übrigens nur sehr schwer nachvollziehbar. Man könnte zunächst argumentieren, daß sich die Größe eines Parameters für ein offenes Feld erst zur Laufzeit ergibt und die verwendeten Mechanismen Schwierigkeiten haben, darin die konstante Größe eines konstant übergebenen Parameters unterzubringen.

7 Dies stimmt aber nicht, da alle Compiler für ARRAY OF CHAR Konstante akzeptieren. Man findet dieses Verhalten in fast allen Handbüchern besonders hervorgehoben. Logisch, daß eine Implementierung, in der man String-Konstante nur unter Schwierigkeiten verwenden kann, nicht sonderlich komfortabel wäre. Aber wenn dies schon für CHAR geht, warum dann nicht für BYTE? SYSTEM.BYTE ist - obwohl nicht Sprachbestandteil wie CHAR - fest im Compiler "verdrahtet", eine Sonderbehandlung sollte einfach möglich sein. Die Berechnung der Parametergröße ist bei Zeichenkonstanten, in denen jedes Zeichen genau ein Byte belegt natürlich besonders einfach, aber auch alle anderen Konstante müssen bei der Übersetzung in Bytefolgen dargestellt werden. Wir können also nur hoffen, daß diese Einschränkung - die zurecht nur als Implementierungs-Beschränkung bezeichnet wird - möglichst bald von den Herstellern aufgehoben wird. Dies würde bei geringem Aufwand die Möglichkeiten, den ARRAY OF BYTE-Trick sauber zu benutzen deutlich verbessern. Zum Abschluß auch dieses Mal wieder ein Modul - es kombiniert die Bitmanipulationen der letzten Folge mit beliebig großen Parametern beliebigen Typs und heißt daher BoolOps; Sie finden es in Listing 1. In der nächsten Folge beschäftigen wir uns etwas mit varianten Records und insbesondere mit den Auswirkungen des Weglassens des Tag-Felds.

8 Listing 1: Definitions- und Implementationsmodule BoolOps DEFINITION MODULE BoolOps; (* (C) Robert Tolksdorf fuer ST-Computer, 8/90 *) FROM SYSTEM IMPORT BYTE; PROCEDURE And(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE); PROCEDURE Or(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE); PROCEDURE Xor(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE); PROCEDURE Not(VAR a: ARRAY OF BYTE); PROCEDURE Imp(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE); PROCEDURE Nand(VAR a:array OF BYTE; b: ARRAY OF BYTE); PROCEDURE Nor(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE); PROCEDURE Nimp(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE); END BoolOps. IMPLEMENTATION MODULE BoolOps; (* (C) Robert Tolksdorf fuer ST-Computer, 8/90 *) FROM SYSTEM IMPORT BYTE, VAL; PROCEDURE And(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE); WHILE (i<=high(a)) AND (i<=high(b)) DO a[i]:=val(char,val(bitset,a[i])*val(bitset,b[i])); i:=i+1 END And; PROCEDURE Or(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE);

9 a[i]:=val(char,val(bitset,a[i])+val(bitset,b[i])); END Or; PROCEDURE Xor(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE); a[i]:=val(char,val(bitset,a[i])/val(bitset,b[i])); END Xor; PROCEDURE Not(VAR a: ARRAY OF BYTE); a[i]:=val(char,val(bitset,a[i])/{0..15}); END Not; PROCEDURE Imp(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE); a[i]:=val(char,(val(bitset,a[i])-val(bitset,b[i]))/{0..15}); END Imp; PROCEDURE Nand(VAR a:array OF BYTE; b: ARRAY OF BYTE); a[i]:=val(char,(val(bitset,a[i])*val(bitset,b[i]))/{0..15}); END Nand; PROCEDURE Nor(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE);

10 a[i]:=val(char,(val(bitset,a[i])+val(bitset,b[i]))/{0..15}); END Nor; PROCEDURE Nimp(VAR a: ARRAY OF BYTE; b: ARRAY OF BYTE); a[i]:=val(char,val(bitset,a[i])-val(bitset,b[i])); END Nimp; END BoolOps.