Konzepte

Inhaltsübersicht HPS WS 2004/05
Teil 2
- Grundlagen (1,2)
- Konzepte imperativer Programmiersprachen (2,3)
- Deklarative Programmiersprachen (4)
- Objektorientierte Programmiersprachen (5,6)
- Programmierung von Smart Cards: Java Card (7)
- Wissenschaftliches Rechnen: Fortran (8)
- Wirtschaftsanwendungen: Cobol (8, 9)
- Skriptsprachen (9)
Konzepte
imperativer Sprachen
- Formale Semantik
- Operationale Semantik mit ASMs (10)
- Operationale Semantik mit natürlicher Semantik und SOS (11)
- Denotationelle Semantik (12, 13)
- Axiomatische Semantik (14)
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
1
Funktional vs. Imperativ
Variable
● Funktionale Sprachen:
–
basieren auf λ-Kalkül
–
Ergebnis von Berechnungen sofort weiterverarbeitet (als Argument)
–
keine Nebenwirkungen von Operationen (zumindest theoretisch)
–
kein Zustandsbegriff
–
Variablenbegriff der Logik
Variable als ADT:
Datentyp VARIABLE(T)
Konstruktoren:
create:
→VARIABLE(T)
write: T × VARIABLE(T)
→ VARIABLE(T)
Operationen:
read: VARIABLE(T)
→T
Axiome
∀x,y: T; v: VARIABLE(T):
write(x,write(y,v)) = write(x,v)
read(write(x,v)) = x
● Imperative Sprachen:
–
Zustand explizit als Menge von Variablen
–
Programmlauf ist Zustandstransformation durch Zuweisungen
–
Zuweisung ist Nebenwirkung anschließend an Ausdrucksberechnung
–
Variable ist Tripel (Behälter, Inhalt, Referenz)
● Behälter: Speicherplatz
● Inhalt: Wert
● Referenz: Identität der Variablen (Adresse?), oft nicht explizit zugänglich
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
3
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
4
Variable: Klassifikation
Bindung und Lebensdauer
● anonyme Variable:
– Variable nur über Referenz zugreifbar,
Referenz ist Wert einer anderen Variablen
– durch expliziten Konstruktoraufruf eingeführt
● Zuordnung von Namen zu Objekten
– Wert-, Bedeutungsbindung,
– statisch, dynamisch, usw., alles wie gehabt
● Lebensdauer von Variablen:
● vereinbarte Variable:
– Variable durch Vereinbarung v: T eingeführt
– lokal - lokal vereinbart
– gebunden an Bezeichner v
● implizite Variable:
– Variable implizit vereinbart bei erster Benutzung (Fortran, Basic, ...)
bequem, aber sehr gefährlich: Schreibfehler bleiben unbemerkt
– unbeschränkt - global vereinbart oder anonym
– persistent - auch in anderen Programmläufen zugreifbar
Im folgenden: „Name“ bedeutet entweder „Bezeichner“ oder allgemeinere
Beschreibung des Zugriffspfads zu einer Variablen, z.B. a[i], a.b.c, ...
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
5
Zugriffsrechte
– nur eine Zuweisung zulässig (write-once Variable),
– zur Übersetzungszeit oder bei Vereinbarung
● nur Lesen:
– Zuweisungen nur in dem Modul/Klasse, der Vereinbarung enthält (read-only
Variable)
● privat:
– Lesen und Zuweisen nur in dem Modul/Klasse, der Vereinbarung enthält
Zugriffsrechte beschränken den Gültigkeitsbereich von Variablenbezeichnern,
nicht die Lebensdauer
Höhere Programmiersprachen WS 2004/2005
Höhere Programmiersprachen WS 2004/2005
6
Datentypen imperativer Sprachen
● statische/dynamische Konstante
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
7
● Skalare Typen:
– Grundtypen: Integer, Float, Complex(?) mit verschiedenen Längen, Boolean,
Character, meist pragmatisch definiert
– Aufzählungstypen mit extensionaler Definition.
● Zusammengesetzte Typen:
– definiert mit Typkonstruktoren array, record (zusätzlich set, file in Pascal)
– Definition neuer Typen durch den Programmierer
– Sonderfall Text (string): spezielle Reihung oder spezieller zusammengesetzter
Typ
● Prozedurtypen:
–
gegeben durch Signatur proc(partyp1,...,partypn): restyp
● Referenztypen:
–
Zeiger auf Objekte anderer Typen
–
Zeiger auf Objekte einer Klasse in oo Sprachen
–
Spezialwert void oder nil: leerer Zeiger
● Sonderfälle: Vereinigungstypen, Ströme, Klassen objektorientierter Sprachen, ...
Vorsicht: Alle Grundtypen und Reihungslängen durch Prozessoreigenschaften oder Speicherumfang beschränkt!
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
8
Ausdrücke
Reihenfolge Operandenzugriff
● Funktionaler Anteil von imperativen Sprachen (Nebenwirkungen möglich)
● Auswertungsreihenfolge links – rechts
● Problembereiche:
● Beispiel: i + i++
– Reihenfolge des Operandenzugriffs - ideal Reihenfolge beliebig, wegen
Optimierungsmöglichkeiten, Verbot der Trickprogrammierung
● Linksauswertung: 2 * i
– Reihenfolge der Operationen
● Rechtsauswertung: 2 * i + 1
● Berücksichtigung von Prioritäten und Klammern
● Indeterministische Auswertung
● Def. zwingend notwendig wegen Genauigkeit numerischen Rechnens
– beides möglich
● Spezialprobleme:
– bei unterschiedlichen Ergebnissen jedoch sinnvoller Weise verboten
– faule oder strikte Berechnung von and und or?
– Berücksichtigung von Überlauf usw. bei Numerik
– div und mod bei negativen Operanden
– ...
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
9
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Reihenfolge Operationen
Höhere Programmiersprachen WS 2004/2005
10
Zuweisung
●
●
●
●
Linke Seite := Rechte Seite
Linke Seite identifiziert Behälter b
Rechte Seite identifiziert Wert v
Zustandstransformation:
<b> := v
– Bedingung: Typ(b) = Typ(v)
(eventuell nach Typanpassung)
● Zentrale zustandsändernde Operation
● Klar bei Klammern und Operationspriorität
● Bei ungeklammerten, gleichpriorisierten Operationen: Assoziativität
● Beispiel: minint * (-1) * (-1)
● Linksassoziativität: error
wenn Codierung im Zweierkomplement,
● Auch Sprünge sind Zuweisungen (an den Befehlszähler)
● Rechtsassoziativität: minint
● Kopiersemantik (Normalfall):
–
Zuweisung weist Kopie des Werts der RS zu, oder
–
Operationen verarbeiten Kopie ihrer Operanden
● Alternative Zeigersemantik(LISP):
–
Zuweisung und Operationen bearbeiten die Originale
● x := 7; y := x; x := 5
● Bei Zeigersemantik gilt dann y = 5
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
11
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
12
Sprunganweisung
Bedingte Anweisungen
● Einfacher Sprung: goto marke
● Indizierter Sprung (Fortran):
goto (l1,l2,...,ln; i) i [1,n]
– Indizierter Sprung ist maschinennaher Ersatz der Fallunterscheidung
● Sprung auf Markenvariable (indirekter Sprung, Fortran):
markenvariable := marke; ...
goto markenvariable
● Einfache bedingte Anweisung:
if B then A else A' end
– B boolescher Ausdruck
– Alternative: B ganzzahlig, Test auf ≠ 0: wahr,
– A, A' Anweisungsfolgen, else-Teil kann fehlen
● Arithmetisches if (Fortran I,II):
if (Ausdruck) marke1,marke2,marke3
● Vorsicht bei Sprachen ohne end (oder anderes Schlußzeichen): dangling else
● Anweisungsfolgen müssen geklammert sein ({...} oder begin...end)
● Bedeutung:
h := Ausdruck;
if h < 0 then goto marke1
elsif h = 0 then goto marke2
elsif h > 0 then goto marke3
end
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
13
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Fallunterscheidung
–
14
Implementierung
● case expr
when x_1 then A_1
when x_2 then A_2
...
when x_n then A_n
else A_0
end
– Fallausdruck expr und Fallmarken: gleicher Typ integer, character
oder Aufzählungstyp
– Fallmarke: Einzelwert, Intervall a..b oder Liste von beidem
–
Höhere Programmiersprachen WS 2004/2005
Fallmarken alle verschieden (sonst nur if-then-else-Kaskade möglich)
● Kaskade von bedingten Anweisungen:
e := expr;
if e = x_1 then A_1
elsif e = x_2 then A_2
...
elsif e = x_n then A_n
else A_0
end
● Sprungleiste, wenn Fallmarken aus ,,kleinem'' Intervall und dicht
● Kombination von beidem
Wenn Fallausdruck keine Fallmarke liefert und else-Teil fehlt:
Leeranweisung
● Theoretisch führt der letzte Fall zum Programmabsturz, nicht zur
Leeranweisung, vgl. Dijkstras wp-Kalkül.
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
15
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
16
Fallunterscheidung nach Typ
Schleifen
● Fallunterscheidung nach dynamischem Typ eines Objektes
–
Ziel: explizit programmierte ,,Polymorphie'',
Anwendung verschiedener Operationen abhängig vom Typ
–
Beispiel: Algol 68, Ada, Sather
–
Typkennung muß explizit oder implizit gespeichert sein
● Anfangsgesteuerte Schleife
while B loop S end
● Endgesteuerte Schleife
loop S until B end
● Zentralgesteuerte Schleife
loop A; exit when B;
A'; exit when B';
A'';
...
end
● Vorteil:
– erlaubt Polymorphie auch in nicht oo Sprachen
● kann z.B. in C, ... mit gewöhnlicher Fallunterscheidung simuliert
werden, wenn die Typen als ganze Zahlen codiert sind
● Zählschleifen
– simuliert Polymorphie auch bei nicht konformen Unterklassen
● Nachteil: mühsame Handprogrammierung
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
17
Zählschleife
18
● Beispiel:
for i:=1 step k to n do
print i;
od
–
● Was passiert, wenn n=maxint?
– in den meisten Sprachen: beliebige Variable
Problem: Zähler kann versehentlich in innerer Schleife wieder benutzt oder
unabsichtlich verändert werden
– Ada: dynamische Konstante, lokal in Schleife vereinbart, keine Änderung möglich
● Schrittweite sollte statisch bekannt sein
● Schrittweite und Endwert pro Schleifenaufruf nur einmal berechnen!
● Schwierige Implementierung: Fehler bei u = -maxint, o = maxint vermeiden
Höhere Programmiersprachen WS 2004/2005
Höhere Programmiersprachen WS 2004/2005
Maxint-Problematik bei Schleifen
● Allgemein:
for i:=u step s until o loop S end
● Algol 60:
for i:= u step s until o,
u' step s' until o'
...
do A
● C, C++, Java schreiben die Implementierung vor:
for (init; test; erhöhe) A
● Zähler:
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
19
● Was passiert, wenn k dynamisch gesetzt wird?
● Betrachte k<0:
– Was passiert bei n = -maxint?
– Was passiert bei n = -maxint-1?
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
20
Vorzeitiges Verlassen von Schleifen:
benannte Schleifen, exit
Duffs Trick
oder: wenn in C, C++ einige breaks fehlen
/* Duff's device */
int main (){
int a = 11 ; /* arbitrary number > 0 */
int n = ( a + 4 ) / 5 ;
● Vorzeitiges Verlassen von Schleifen mit break möglich
● Aber break wird auch zum Verlassen von Fallunterscheidungen usw.
benutzt
switch ( a % 5 )
{
case 0: do
{
putchar
case 4:
putchar
case 3:
putchar
case 2:
putchar
case 1:
putchar
} while (
}
● Lösung: Markieren von Schleifen:
marke_1: loop ...
marke_2: loop ...
if B then exit marke_1 end;
...
if B' then exit marke_2 end;
...
end; -- loop marke_2
end; -- loop marke_1
praktische Anwendung: Aufrollen von Schleifen (hier fünffach) aus Effizienzgründen, wenn
tatsächliche Anzahl Durchläufe unbekannt
In Java ist diese Konstruktion unzulässig, vgl. Java Language Specification, Abschnitt 14.10
21
das gleiche Problem
etwas übersichtlicherer Code
int main (){
int a = 11 ; /* arbitrary number > 0 */
int n = ( a + 4 ) / 5 ;
switch ( a % 5 )
{
case 0:
putchar ( '0'
case 4:
putchar ( '4'
case 3:
putchar ( '3'
case 2:
putchar ( '2'
case 1:
putchar ( '1'
}
while ( --n ) {
putchar ( '0' ) ;
putchar ( '4' ) ;
putchar ( '3' ) ;
putchar ( '2' ) ;
putchar ( '1' ) ;
} ;
)
)
)
)
)
Höhere Programmiersprachen WS 2004/2005
22
● Terminologie
– echte Prozedur, Unterprogramm: Prozedur ohne Ergebnis
– Funktionsprozedur, Funktion, Funktionsunterprogramm: Prozedur mit Ergebnis
– Methode: Prozedur in oo Sprache
– Prozedurvariable, formale Prozedur: Variable/Parameter mit Prozedur als Wert
● Vereinbarung
– geschachtelte Prozeduren möglich (in Algol-Sprachen)
– keine Schachtelung in Fortran, C, oo Sprachen
Ausgabe:
ggoos(187)% a.out
10432104321
ggoos(188)%
;
;
;
;
;
● Aufruf
– parameterlos: p() oder p (uniform referent: Zugriff auf Variable/Funktionsergebnis)
– Argumente nach Position: p(ausdruck_1,...,ausdruck_n)
– Argumente mit Schlüsselwort p(Datei="file", modus=lesend)
● fehlende Argumente ersetzt durch Standardwerte, definiert bei Vereinbarung
● auch Mischung mit Positionsschreibweise erlaubt, Positionsargumente zuerst
● Ergebnis
– zugewiesen an Prozedurbezeichner: p := Ergebnis
– mitgeteilt durch return Ergebnis
– zugewiesen an Spezialvariable: res := Ergebnis
– Ergebnis kann ignoriert werden: Fortran, C, viele oo Sprachen
printf ( "\n" ) ;
Höhere Programmiersprachen WS 2004/2005
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Prozeduren und Funktionen
}
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
;
;
;
;
;
printf ( "\n" ) ;
● Schleifenmarken nur in innerhalb der geschachtelten Schleife gültig
(zusätzliche Regel über Gültigkeitsbereiche)
Höhere Programmiersprachen WS 2004/2005
)
)
)
)
)
;
}
● Verlassen einzelner, auch geschachtelter Schleifen möglich
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
( '0'
( '4'
( '3'
( '2'
( '1'
--n )
Ausgabe:
ggoos(185)% a.out
10432104321
ggoos(186)%
23
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
24
Prozedur- und Funktionsvereinbarung
Prozedur- und Funktionsaufruf
● Funktion (mit Schlüsselwortparametern):
p(Datei: string := "stdin",
modus: Mode,
pufferzahl: int := 2): Fehlermodus is A end;
● Parameterart kennzeichnen:
–
kein Kennzeichen: Eingabeparameter
–
out oder &: Ausgabeparameter
● Anweisung:
call Prozedur(ausdruck_1,...,ausdruck_n)
● Ausdruck:
call Funktion(ausdruck_1,...,ausdruck_n)
● Ausdrücke 1 ... n heißen aktuelle Parameter
– inout oder &&: transienter Parameter
● Parameterart in manchen Sprachen auch im Aufruf gekennzeichnet
● Fehlerbehandlung
–
mit ganzzahligem Fehlercode als Ergebnis oder
mit Ausnahmebehandlung (später)
● mögliche Ausnahmen als Teil der Signatur (Java)!
–
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
25
Parameterübergabe
● Zeitpunkt der Auswertung:
– Strikter (Wert-)Aufruf (strict evaluation)
– Fauler Aufruf (call-by-need, lazy evaluation)
● Gültigkeitsbereich von Parameterbezeichnern:
– wie lokale Variable im Rumpf der Prozedur (in den meisten Sprachen)
– wie lokale Variable in einem Block, der den Rumpf umgibt
● schlecht, weil Parameterspezifikation im Rumpf überschreibbar
– zusätzlich an allen Aufrufstellen, wenn Schlüsselwortparameter benutzt werden
● Vorsicht: formale Prozeduren/Prozedurvariable nicht mit Schlüsselwortparametern
aufrufbar!
Höhere Programmiersprachen WS 2004/2005
Höhere Programmiersprachen WS 2004/2005
26
Parameterübergabe: Prinzipien
● Verfahren:
– Wertaufruf (call-by-value)
– Ergebnisaufruf (call-by-result)
– Referenzaufruf (call-by-reference)
– Namensaufruf (call-by-name)
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
27
● Wertaufruf
– Parameter: lokale Variable, bei Aufruf mit Argument initialisiert
● Ergebnisaufruf
– Parameter: lokale Variable, bei Rückkehr an das Argument zugewiesen
– Argument muß Variable sein
● Referenzaufruf
– Parameter: lokale Konstante, initialisiert mit Verweis auf Argument
– Zugriff auf Parameter: indirekter Zugriff auf Argument (lesend/schreibend)
– Argument muß Variable sein
● Namensaufruf
– Argument: Funktion, die wahlweise Wert oder Verweis auf Argument liefert
– Parameter: initialisiert mit Argumentfunktion
– Jeder Zugriff auf den Parameter ruft die Funktion auf
– Argument muß Variable sein, wenn am Parameter zugewiesen wird
● Strikter (Wert-)Aufruf
– Parameter: lokale Konstante, initialisiert mit Argument
● fauler Aufruf: wie strikter Aufruf, aber Initialisierung bei erstem Zugriff
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
28
Verschiedene
Parameterübergabemechanismen
Wert-Ergebnis- vs. Referenz-Aufruf
● Wert-Ergebnis-Aufruf: Ausgabe
„0“
● Referenz-Aufruf:
„1“
Ausgabe
●
●
n: INT;
2w: 2. Parameter Wertaufruf
●
proc p (x: INT);
●
begin
x := x+1; print (y);
end;
●
m:INT := 1;
???: Art Parameterübergabe offen
y:INT := 0;
p(y);
Verfahren
m
n
j
k
Wert
Wert/Erg.
Referenz
Name
faul
5
2
6
7
5
6
6
10
17
6
2
2
6
7
2
4
4,2w
4,2w
10
4
proc p (??? j:INT;
??? k: INT): INT;
begin
j := j+1;
m := m+k;
p := j+k
end;
n := p(m, m+3);
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
29
Namensaufruf (Jensens Trick)
30
● Modellvorstellung, die die Sichtbarkeit und Zuordnung Bezeichner Vereinbarung regelt, auch bei rekursivem Aufruf:
– Reserviere Speicher auf dem Keller für Parameter (ohne Reihungen) und
Organisation
– Kopiere Prozedurtext
– Ersetze alle lokalen Bezeichner, einschl. Parameter, in der Kopie durch
neue Bezeichner
– Berechne Argumente (im Kontext des Aufrufers) und weise sie an die
neu bezeichneten Parameter zu
– Unterprogrammaufruf (Befehl)
– Speichere Rückkehradresse im Keller
– Ausführung der Prozedurkopie
– Prozedurrückkehr
– Zuweisung der Ergebnisparameter an ihre Argumente, falls vorhanden
(auch vor Rückkehr möglich)
– Beseitige Prozedurkopie
● Analoges Schema für begin-end Blöcke mit lokalen Vereinbarungen
begin
real s; s:=0;
for i:=1 step 1 until n do
s:= s + x*y;
sum:= s;
end;
erg := sum(i,n,a[i],b[i]);
Höhere Programmiersprachen WS 2004/2005
Höhere Programmiersprachen WS 2004/2005
Prozeduren: Ausführungsprinzip
real procedure sum(i,n,x,y);
value n;
integer i,n;
real x,y;
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
31
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
32
Ausnahmebehandlung
Steuerparallelität
● Ziel: Fehlerbehandlung so, daß eine Anweisung (ein Block) ordnungsgemäß zu
Ende geführt wird.
begin ... raise overflow; ...
except e when overflow then Fehlerbehandlung
end
● Methode: Auslösen der Ausnahme (raise, eventuell implizit durch Hardware)
springt auf den Beginn der passenden Fehlerbehandlung.
● Wenn keine Fehlerbehandlung lokal vorhanden: Suche nach Fehlerbehandlung im
dynamisch umfassenden Block, eventuell unter Beendigung der Prozedur, die den
Fehler enthielt.
● Ausnahmebehandlung wie beschrieben in Ada, Modula-3, Sather, Java
● Java zählt Ausnahmen zur Signatur von Klassen/Prozeduren
● Allgemeinere Formen der Ausnahmebehandlung, z.B. mit Wiederaufsetzen, in
MESA (Xerox PARC), vgl. auch J. Goodenough, CACM Juli 1975
● Vorsicht: Ausnahmebehandlung und Fehlerbehandlung über FehlercodeRückmeldung wie in C, C++ nicht nebeneinander im gleichen Programm benutzen!
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
33
Mehrfädige Programmierung (nebenläufig, multithreading, multitasking):
1 erzeuge neuen Prozeß (Faden, thread) p, einschl. Speicherreservierung für Keller
2 weise p Programmstück zu (Funktionsaufruf (Normalfall), spezielle task (Ada))
3 starte Prozeß
4 Kommunikation oder Synchronisierung mit anderen Prozessen
5 Prozeßende: Rückmeldung Ergebnis (?), Stop des Prozesses, Ende des Fadens, Ende
Speicherreservierung Keller
● 1-3 oft zusammengefaßt zu einer Operation
faden_id := fork Funktion(arg_1,...,arg_n)
● Kommunikation, Synchronisierung mit Hilfe von Semaphoren (gem. Speicher) oder
Botschaften oder abgeleiteten Verfahren (Monitore, Fernaufruf, Rendezvous)
● Prozeßende: Unterscheide
– Vater läuft simultan weiter, Sohn informiert Vater über Prozeßende
– mehrere gleichzeitig gestartete Prozesse warten aufeinander, bevor Vater fortsetzt
– erster fertiger Prozeß beendet alle anderen Söhne und setzt Vater fort
– Sohn läuft unabhängig vom Vater, Vater eventuell früher fertig als Sohn
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Datenparallelität
Höhere Programmiersprachen WS 2004/2005
34
Programmstruktur, Abstraktionen
● Parallelzuweisung:
(v_1, ... ,v_n) := (e_1, ... ,e_n)
Auch Vertauschung (x,y) := (y,x) zulässig
● Parallele Schleife:
for i:=u step s until o
do in parallel
a[I(i)]:=f(a[I1(i)],...,a[In(i)])
end
alle (o-u+1) Durchläufe simultan ausführen, jeweils indiziert mit
Prozeßnummer i.
– simultan: (o-u+1) parallele Prozesse auf (o-u+1) Prozessoren oder zeitlich
verzahnt auf weniger Prozessoren
– Voraussetzung: keine Datenabhängigkeit zwischen den einzelnen
Durchläufen
– Beispiel: Berechnung von a[i] darf nicht von der Kenntnis von a[i+1]
abhängen
– Ausnahme: selbststabiliserende Berechnungen: korrekt, unabhängig
davon, ob alter oder neuer Wert von a[i+1] benutzt
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
35
● Ziele
–
Gliederung des Programms in Module, Klassen, ...
–
Unterstützung von Abstraktionen:
● Block
● zusammengesetzte Operation: Hauptprogramm, Prozedur
● zusammengesetztes Objekt: Verbund
● benutzerdefinierter Typ: Klasse, Vererbung
–
Durchsetzung des Geheimnisprinzips
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
36
Blockstruktur
Prozedurale Abstraktion
● Block (Samelson 1958): Zusammenfassung von Anweisungen und zugehörigen
Vereinbarungen zu größerer Anweisung
– eigenständiger Gültigkeitsbereich: globale gleichbenannte Größen nicht
zugänglich
– lokale Größen extern nicht sichtbar
– lokale Variable haben nur lokale Lebensdauer
–
–
– Abbildung der Prozeduraufrufhierarchie auf dynamische Schachtelung
von Blöcken
Höhere Programmiersprachen WS 2004/2005
● ,,enthält'' logisch alle anderen Programmeinheiten
(auch bei getrennter Übersetzung)
In Fortran, C und oo Sprachen: spezielle Prozedur
Parameter: Text der Kommandozeile
● Prozedur:
– Zusammenfassung von Anweisungen (Makro)
● Programm ist Block mit geschachtelten Unterblöcken
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
● Hauptprogramm:
– In ALGOL, Pascal, ...: umfassender Block
37
logische Einheit: abstrakte Operation
–
ist zusammen mit Typdefinitionen, anderen Operationen
Teil einer umfassenderen Abstraktion Modul
–
in oo Sprachen: Teil einer Klasse, d.h. eines Objekttyps
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Gliederung von Programmen
Höhere Programmiersprachen WS 2004/2005
38
Globale Variablen
● Common (Fortran) oder Data (Cobol):
In beliebigen Unterprogrammen (UP) möglich:
● Baumartige Gliederung in Blöcke und Prozeduren in Algol, Pascal, ...
● Common X1,...Xm
– Geschachtelte Gültigkeitsbereiche (statisch)
– Geschachtelte Lebensdauer (dynamisch)
– Umbenennung der Variablen möglich:
In UP1(...): Common X11,...,Xm1
– Zugriffe auf globale Größen möglich
In UP2(...): Common X12,...,Xm2
● Flache Hierarchie in Fortran, C, oo-Sprachen:
...
In Upn(...): Common X1n,...,Xmn
– Module, Klassen oder Übersetzungseinheiten auf Tiefe 0
– Prozeduren auf Schachtelungstiefe 1
– Zugriff auf globale Größen des eigenen Moduls, Klasse, ... beschränkt
– Unterschiedliche Typisierung möglich, z.B. statt complex zweimal real,
Zusammenfassung zu Reihungen unterschiedlicher Länge, ...
– Möglichkeit globaler Größen, die zu mehreren Unterprogrammen,
Übersetzungseinheiten, ... gehören (Common Zonen, statische Variable)
– Common Zone definiert Gruppe von Ups, die sie benutzen
● hierdurch auch unterschiedliche Anzahl der Variablen
● Problem: nur eine einzige Gruppe möglich
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
39
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
40
Unterprogramme mit mehreren
Einstiegspunkten
Benannte Common Zonen
● Unterprogramme in Fortran können mehrere Prozedurköpfe enthalten mit
unterschiedlicher Parametrisierung
● Ziel:
– Gruppierung mehrerer Operationen, die lokale gemeinsame Daten benutzen
– Gruppierung von Operationen, die gemeinsame Codestücke enthalten
● Alternative zum Gebrauch benannter Common Zonen: Geheimnisprinzip
– kontrollierter Zugang: Jede Operation soll nur auf die nicht-lokalen Größen
zugreifen können, die sie logisch benötigt
– Abschottung: Gruppen von Operationen sollen lokal die Größen vereinbaren
können, die sie benötigen;
andere haben keinen Zugang
– Austauschbarkeit: Implementierungen von Operationsgruppen sollen
austauschbar ohne Rückwirkung auf andere, solange Schnittstelle gleich bleibt
– Wiederverwendung: Andere sollen Operationsgruppen nur mit der Kenntnis der
Schnittstelle wiederverwenden können
● Fortrans Unterprogramme mit mehreren Eintrittspunkten / mit benannten Common
Zonen erlauben dies zu formulieren, aber ohne Zwang
● Common Bereiche können benannt werden:
– Common /Name1/ X1,...,Xm
Common /Name2/ Y1,...,Ym
– In UP1(...): Common/Name1/ X1,...,Xm
In UP2(...): Common/Name2/ Y1,...,Ym
...
In UPn(...): Common/Name1/ X1,...,Xm
Common/Name2/ Y1,...,Ym
– Jeder Name definiert Gruppe von Unterprogrammen
– Unterprogramm kann zu mehreren Gruppen gehören
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
41
Modularisierung
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
42
Programmieren im Großen
● Zuordnung von Operationen zu Daten
– Bearbeitungseinheiten bei der Entwicklung von Programmen,
● Partitionierung der Prozeduren bezüglich verwendeter Bereiche
– Zugriff über definierte Schnittstellen (öffentliche Sicht),
Konsistenzprüfung zur Übersetzungszeit,
● Hervorhebung der Schnittstelle:
– Trennung der Schnittstelle von ihrer Implementierung (private Sicht),
austauschbare Implementierungen.
– Modula, Ada: Unterscheidung von Definition (Schnittstelle) und
Implementierung
– C: .h-Datei definiert Schnittstelle
– oo Sprachen: Unterscheidung der öffentlich und der nur privaten
Operationen
● Probleme:
– Typüberprüfung an der Schnittstelle nötig
– nur ein Exemplar jedes Moduls außer in oo Sprachen
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
43
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
44
Beispiel: Keller (Integer) in C
Implementierung
Modul - ADT Implementierung
● ADT = (Konstruktoren, Operationen, Axiome)
Schnittstelle
● Modul =
static int *stack, mark, size;
static int *realloc(int *s)...;
int top(void)
{return mark?stack[mark]:ERROR;};
int pop(void)
{return mark?stack[mark--]:ERROR;};
#define ERROR minint
extern int top(void);
extern int pop(void);
extern void push(int);
– Schnittstelle (öffentliche Sicht):
● Definition von Konstruktoren (Typdeklaration),
● Operationen,
– Implementierung (private Sicht):
● der Konstruktoren und Operationen,
void push(int i)
{if (++mark >= size)
stack=realloc(stack);
stack[mark]=i;
};
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
● muß Axiomen des ADTs genügen.
Höhere Programmiersprachen WS 2004/2005
45
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Modul für ADT Keller in C
Implementierung
int top(stack s){
return
s.mark?s.stack_impl[s.mark]:ERROR;};
...
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
46
Generische Module
● Mehrsortige Algebren mit einigen unspezifizierten Sorten.
Schnittstelle
typedef struct stack {
int *stack_impl;
int mark, size;
} stack;
Höhere Programmiersprachen WS 2004/2005
● Schnittstelle und Implementierung enthalten Typvariablen.
#define ERROR minint
extern int top(stack);
extern typdef stack;
extern int pop(stack);
extern void
push(stack,int);
47
● Instanziierung mit konkreten Typen erzeugt Modul.
● Definiert durch textuelle Substitution der Typvariablen durch konkreten
Typ.
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
48
Generischer Keller in C
Generischer Keller in ADA
Schnittstelle
Namensbildung durch Makrosubstitution
generic type ELTS is private;
package STACKS is
type STACK is private;
function top(s: in STACK) return ELTS;
function pop(s: in STACK) return ELTS;
procedure push(s: in STACK, e: in ELTS);
private type STACK is record
stack_impl:access array(Integer range<>)of ELTS;
#define STACK (type)\
typedef struct type ##_stack {\
type *stack_impl;\
int mark, size;\
} type ##_stack;\
\
type type ##_top(type ##_stack s){\
return\
s.mark?s.stack_impl[s.mark]:ERROR;};\
...
mark,size : Integer;
end STACK;
end STACKS;
Implementierung und Instanziierung
#define TOP(type,stack) type ##_top(stack)
...
package body STACKS is ... end STACKS;
package INT_STACK is new
STACKS(ELTS=Integer);
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
49
Modul, Klasse und Typ
– Modul-Definition:
module M is
type MT is
record
x1:X1,
x2:X2,
...
end record;
proc1(m:MT,...);
proc2(m:MT,...);
...
end; -- M
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
–
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
50
Abstrakte vs konkrete Klasse
Abstrakte Klasse:
Konkrete Klasse
Abstrakte Klasse
module K is
type KT is
record
x1:X1,
x2:X2,
...
abstract class Stack
(ELTS) is
top : ELTS;
pop : ELTS;
push (e: ELTS);
end;
proc(...),
...
end record;
end K;
51
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
class ArrayStack(ELTS <
ORDERED(ELTS))
subtype of Stack(ELTS) is
private stack_impl :
ARRAY(ELTS);
private mark, size :
INTEGER;
private realloc;
top : ELTS is ... end;
pop : ELTS is ... end;
push (e: ELTS) is ...
end;
end;
Höhere Programmiersprachen WS 2004/2005
52
Weitere Konzepte: Namensräume und
Sichtbarkeit
Abstraktes Programmieren
● Typen:
● minimale Eigenschaften von Objekten im Kontext einer Anwendung
– Untertypbeziehungen:
● Objektmengen (Typen), die diesen Anforderungen genügen.
● Entspricht struktureller Konformität
– Objekt,
● Programmieren in Termen von Schnittstellen
– Teilweise abstrakte Klassen:
– Kernmethoden
Basisbausteine (abstrakt)
– Abgeleitete Methoden
Zusammengesetzt aus Kernmethoden, können bereits in abstrakter
Klasse implementiert werden
Höhere Programmiersprachen WS 2004/2005
– Pakete (im Java Sinn, nicht im ADA Sinn),
● Zugriffskontrolle
– Typschranken für Typparameter:
● minimale Eigenschaften von Typen
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
● Namensräume
53
– Klasse, Superklasse, Freundklassen
– Paket , Freund,
● Metaprogrammieren, Metaklassen, Reflexion
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
Probleme mit Sichtbarkeiten
class A
54
Überladen
● Mehrere Methoden mit gleichem Namen, aber unterschiedlichen Signaturen
{ int x; }
class B extends A { int x; }
● Bsp:
class E extands A {
void p(int x)
int x;
void p(long x)
class F extends B {
● Problem: Auflösung
int x;
public void f(int x) {
...
}
}
}
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
55
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
56
Meta-Informationen
Kommentare
● Ziel: Dokumentation des Programmtexts
● Metadaten
● Unterschiedliche Aufgaben:
– Entwicklungsdokumentation (für Test, Wartung)
– Schnittstellendokumentation (Moduln, Klassen, Prozeduren)
– Benutzerdokumentation (bei kleinen Programmen)
– Änderungsdokumentation und Versionskontrolle
– Übersetzersteuerung ???
– Daten über Programme
● Introspektion
– „Programmierung zur Laufzeit“
● Reflexion
● Unterscheide
– geklammerte Kommentare (mit Schachtelungsmöglichkeit): zum
,,Auskommentieren''
– Zeilenkommentare (Kommentarende = Zeilenende): Standard
– Beginn Zeilenkommentar nach Aufgabe gegliedert, z.B. --, --*, --**, usw.
– Besichtigen von Metadaten zur Laufzeit
● Metaprogrammieren
– Erstellen und Modifizieren von Programmen
● Merke:
– Kommentare werden während des Programmentwurfs geschrieben,
oder überhaupt nicht
– schlechte Kommentare sind besser als keine Kommentare
– Programme = Daten (Lisp)
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
57
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
58
Zusammenfassung Teil 2
Pragmas
● Pragmas sind Kommentare zur Übersetzer-/Laufzeitsteuerung
● eingeleitet mit speziellem Kommentarsymbol, z.B. pragma (Ada)
– gültig für Übersetzungseinheit, Modul/Klasse/Prozedur/Anweisung
– nicht an beliebiger Stelle einsetzbar
● Typen
● Pragmas sind implementierungsspezifisch, nicht Teil der Sprache!
● Ablaufsteuerung
● Aufgabenbeispiele:
– Steuerung Sprachumfang (Zulassen zusätzlicher Sprachelemente,
z.B. Maschinensprache-Einschub)
– Feinsteuerung Speicherverteilung
– Steuerung Verteilung
– Steuerung von Testausgaben
● Prozeduren, Module, Klassen
● Ausdrücke
● Überladung, Generizität und Polymorphie
● Bedingungen:
– Übersetzung auch dann korrekt, wenn Pragmas ignoriert werden!?
– Pragmas werden während Symbolentschlüsselung decodiert,
daher nur reguläre Syntax!
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
59
Prof. Dr. Gerhard Goos, Dr. Sabine Glesner
Höhere Programmiersprachen WS 2004/2005
60