Ja, herzlich willkommen.

Wir reden heute über ein neues Thema, wie letztes Mal angekündigt und zwar über Polymorphie,

also sprich über Funktionen, die sich auf verschiedene Datentypen anwenden lassen,

genauer über parametrische Polymorphie und konkret über eine Erweiterung des getypten

Lambda-Calcules, das sogenannte System F.

Ja, gut, also wir, wie gesagt, mit Polymorphie bezeichnen wir eben das Phänomen, dass wir

einen Funktionsnamen haben, den wir auf Objekte verschiedener Typs anwenden können.

Das gibt es in vielen Sprachen, auf viele verschiedene Weisen, zum Beispiel sowas wie

Java Interfaces würden einem das erlauben.

Also ich habe jetzt ein längeres Beispiel im Skript, wir haben es jetzt fünf Sitzungen

vor Semesterende, haben wir es so ein bisschen knapp mit der Zeit, also mache ich jetzt hier

nicht noch Java Beispiele an der Tafel, aber ich nehme an, das kennen Sie alle.

Ich kann Interface implementieren, wo ich, was weiß ich, irgendwelche Shapes als verschiedene

Datenstrukturen repräsentiere, ich habe für jeden Shape eine Draw-Funktion, der Shape

selber kann irgendwie auf sehr unterschiedliche Art repräsentiert werden, das kann, was weiß

ich, ein Kreis sein, repräsentiert durch Mittelpunkt und Radius und andererseits ein

Dreieck repräsentiert durch drei Punkte, also völlig unterschiedliche Strukturen,

kommen beide mit einer Funktion daher, die nennt sich Draw und dann kann ich so Dinge

haben wie Listen von Shapes, die ich dann seriell eine nach der anderen eben auf dem

Bildschirm zeichne, indem ich ständig eine Funktion aufrufe, die Draw heißt, aber dann

natürlich jedes Mal was völlig anderes macht.

Da muss man, wenn man lieber funktionale Programmierung mag, nun nicht die Nase rümpfen,

denn sowas gibt es auch beispielsweise in Haskell, die sogenannten Typklassen, die machen

letztlich nichts anderes.

Also ich kann für Typen ein Interface deklarieren, das im Wesentlichen eigentlich genauso funktioniert

wie bei meinem Java-Beispiel eben, also ich kann zum Beispiel eine Klasse Equality deklarieren

und jedes Mal, wenn ich also einen Typ in diese Klasse Equality schmeiße, muss ich auf ihm

halt ein Gleichheitsprädikat implementieren, auf welche Weise auch immer mir einfällt,

denn da liegen mir Haskell im Grunde keine Restriktionen auf.

Das sind sehr ähnliche Prinzipien und das hat auch einen Namen, das heißt Ad-hoc-Polymorphie.

Das Paper, in dem Typklassen für Java eingeführt werden, heißt How to make ad hoc polymorphism

less ad hoc, aber ad hoc bleibt da eben trotzdem.

Ist auch wie gesagt gut und schön, ja also manchmal will man das, manchmal will man eben

Funktionen haben, die auf verschiedenen Typen definiert sind und nur zufällig gleich heißen,

damit man eben über ein einheitliches Interface auf sie zugreifen kann.

Es gibt auch ganz andere Funktionen, zum Beispiel das übliche, also wenn wir hier, oder wenn

wir die Concat-Funktion nehmen, ja die Concat-Funktion die geht von List A nach List A für beliebigen

Typ A und sie hat eine Definition, ich wiederhole sie nochmal, Concat nil l ist gleich, nicht

i sondern l und Concat von cons x k und l ist rekoziv definiert als cons von x und Concat

kl.

Das ist evidenterweise was völlig anderes, das ist jetzt auch eine Funktion, die funktioniert

für sehr verschiedene Typen, nämlich Listen von allen möglichen Dingen, aber sie tut

eben uniform auf allen diesen Listen dasselbe.

Sie hat eine einheitliche rekozive Definition, die ich nur einmal schreiben muss, während

ich ja zum Beispiel meinem Shape Beispiel, muss ich also für jede Art von Shape, die

ich zeichnen will, eine eigene Draw-Funktion implementieren.

Das heißt also wir haben hier eine völlig andere Art Polymorphie vorliegen als die Ad hoc

Polymorphie da oben, also im Wesentlichen heißt das wir haben einheitliche Implementierung

versus typweise Implementierung und das ganze hier heißt dann parametrische Polymorphie,

ich habe eine Definition die den Typ gewissermaßen nur also in diesem Falle A als Parameter nimmt