14 - Monad-Based Programming [ID:10760]
50 von 388 angezeigt

Die Nodels.

Sergei hat ja letzte Vorlesung schon angekündigt, dass er noch eine andere Charakterisierung von Monaden zeigen möchte.

Die aber die Begrifflichkeit der natürlichen Transformation benötigt.

Deswegen werde ich jetzt erstmal anfangen euch zu zeigen, was natürliche Transformationen sind, wie man das motivieren kann und was man damit tun kann.

Und dann darauf aufbauend eben diese Charakterisierung der Monaden.

Und dann wird sich ja auch später noch zeigen, dass man natürliche Transformationen eigentlich überall brauchen kann.

Und wir werden es dann auch später noch öfter sehen.

Also ich schreibe erstmal die Definition von der natürlichen Transformation hin.

Also natürliche Transformationen bringen irgendwie Funktoren miteinander in Verbindung.

Also das heißt wir brauchen erstmal zwei Kategorien.

Also ich schreibe alles auf Englisch, damit es im Skript nicht durcheinander kommt.

Und dann kommt es dann auf Englisch.

Und dann kommt es dann auf Englisch.

Also ich schreibe alles auf Englisch, damit es im Skript nicht durcheinander kommt.

Werde aber das auf Deutsch halten, außer es besteht jemand drauf, dass ich es auf Englisch halte.

Also wir haben zwei Kategorien und dann zwei Funktoren mit gleicher Signatur.

Also gehen beide von C nach D.

Und dann kann man eben eine natürliche Transformation zwischen diesen beiden Funktoren definieren.

Ich nenne die mal TETA.

Also eine natürliche Transformation ist zunächst mal eine Familie.

Eine Familie von Morphismen in der Zielkategorie D, die eben von FC nach GC gehen.

Und es ist eben wichtig, dass es eine Familie ist.

Man muss für jedes Objekt aus der Kategorie C einen solchen Morphismus angeben, um eine natürliche Transformation zu bekommen.

Das ist aber natürlich nicht das einzige. Diese Dinge müssen noch eine Bedingung erfüllen.

Wir haben ja schon gelernt, dass man Funktionen unter einem Funktor anwenden kann.

Natürliche Transformationen nennen sich deswegen natürlich, weil man entweder zuerst die natürliche Transformation anwenden kann, um den Funktor zu wechseln.

Und dann unter dem Funktor eine Funktion anwenden kann oder es andersrum machen kann.

Dieses Diagramm ist im Allgemeinen als Naturality Condition bekannt.

Wenn man jetzt in die Programmierwelt schaut, dann merkt man auch schon, dass das überall vorkommt.

Zum Beispiel kennt ihr ja schon, oder wisst ihr schon, dass der Listentypkonstruktor in Haskell ein Funktor ist.

Dieses Natürlichkeitsdiagramm kann man zeichnen, zum Beispiel für Listen über irgendein Datentyp.

Und hier auch noch mal Listen über einen Datentyp. Wir nehmen jetzt einfach mal an, dass f und g gleich sind.

Das ist beides mal der Listen-Funktor. Das geht irgendwie zu Listen über b. Und hier genauso.

Und da kann man jetzt zum Beispiel irgendeine Funktion f anwenden unter dem Funktor Liste.

Das heißt ja, dass man diese Funktion komponentenweise anwendet.

Also auf jede Komponente dieser Liste wird das f angewandt und man bekommt eine Liste von bs.

Und was wäre jetzt hier eine Funktion, die da reinpasst? Da gibt es einige.

Unter anderem eben zum Beispiel die Reverse-Funktion.

Wenn ich eine Liste erst mit irgendeiner Funktion bearbeite, also komponentenweise irgendeine Funktion anwende und sie dann umdrehe,

dann bekomme ich das gleiche heraus, wie wenn ich die Liste zuerst umdrehe und dann die Funktion komponentenweise ausfülle.

Mehr Beispiele aus Haskell, Programmierexamples.

Reverse. Was ich vergessen habe zu sagen, ist natürlich wichtig, dass das a hier beliebig ist.

Also ich muss natürlich das Reverse für jeden Typ angeben können. Der Typ ist das, was hier das Objekt in der Kategorie ist.

Also Reverse, dann haben wir zum Beispiel auch Concat in der üblichen Definition.

Also das Diagramm kann ich dann natürlich malen, wenn ich einfach hier nochmal eckige Klammern rummache und hier auch,

dann kann ich entweder erst komponentenweise was ausführen und dann die Liste konkatenieren oder ich konkateniere zuerst und fülle dann elementweise aus.

Wobei das dann hier natürlich unter beiden Funktoren wäre. Also es wäre wirklich elementweise nicht irgendwie pro Liste in der Liste.

Reverse, Concat sind so die einfachsten Beispiele. Dann können wir noch ein einfaches Non-Example geben.

Warum ist das nicht natürlich? Zum Beispiel wenn wir jetzt eine Liste haben. 1, 2, 3. Und wir wenden darauf Sword an.

Dann bleibt natürlich alles gleich. Jetzt können wir aber hier unter dem Funktor der Liste eine beliebige Funktion anwenden.

Teil einer Videoserie :

Zugänglich über

Offener Zugang

Dauer

01:32:47 Min

Aufnahmedatum

2015-06-02

Hochgeladen am

2019-04-25 03:29:03

Sprache

en-US

The course provides a background to various topics of the theory of programming. As a guiding paradigm monad-based functional programming is chosen. The idea of the course is to provide clear computational insights to various concepts of computer science and to practice these by concrete implementations in suitable programming languages such as Haskell.

Lernziele und Kompetenzen:

 

Fachkompetenz Wissen Students demonstrate an understanding of the role of computational monads in the context of functional programming and as a semantic tool for programming and system specification; Students reproduce the main definitions and results on monads, monad combination, and further categorical constructions end explain them from a programming perspective. Anwenden Students use the monad-based approach to formalise examples involving various kinds of computational effects as monads. Students use monads for practical programming in programming languages, such as Haskell. Analysieren Students identify various computational effects as monads and provide an appropriate treatment of problems from various semantic domains (probabilistic, nondeterministic, concurrent), possibly providing a monad-based software implementation. Selbstkompetenz Students will be regularly provided with small challenges in form of exercises to be able to have a gradual progress with the lecture material.    

Tags

functional monads programming haskell equational reasoning
Einbetten
Wordpress FAU Plugin
iFrame
Teilen