Kommandozeilenparser in Haskell - Teil 2

Im ersten Teil des Artikels haben wir Kommandozeilenoptionen mit der Bibliothek System.Console.GetOpt verarbeitet.

Die geparsten Kommandozeilenoptionen wurden, dabei in Form einer Liste zurückgeliefert, die man durchsuchen muss, um festzustellen, ob eine bestimmte Kommandozeilenoption angegeben wurde. Da es für die Weiterverarbeitung der Kommandozeilenoptionen in der Anwendung von Vorteil ist, die Optionen als Record-Typ darzustellen, haben wir eine Umwandlungsfunktion geschrieben, die die Daten von der Form als Liste des Summentyps in den Produkttyp umwandelt.

Der Ansatz führte jedoch dazu, dass wir jede Kommandozeilenoption einmal als Konstruktor im Summentyp, und einmal als Feld im Recordtyp definiert haben. Zusammen mit dem Eintrag in der Optionsliste (vom Typ [OptDescr a]) und dem Code in der Umwandlungsfunktion hatten wir dadurch vier Stellen, die angepasst werden müssten, wenn man z.B. eine Kommandozeilenoption hinzufügt. Allerdings kann es bei späteren Anpassungen leicht passieren, dass man den Summentyp erweitert, aber den Eintrag in der Optionsliste nicht anpasst, ohne dass es hierdurch zu einem Compilerfehler kommt.

Bei der Entwicklung von komplexen Anwendungen sind redundant vorhandene Informationen oft eine Fehlerquelle und führen zu höherem Wartungsaufwand (vgl. auch DRY Prinzip). Um die Redundanz an dieser Stelle zu reduzieren kann man in Haskell die Spracherweiterungen Generics und Literale auf der Typebene einsetzen. Die beiden Spracherweiterungen ermöglichen eine typsichere Abstraktion über die Datenstrukur - insbesondere werden hierdurch Fehler bereits bei der Kompilierung des Programms erkannt, statt erst zur Laufzeit.

Wir wollen in diesem zweiten Teil des Artikels mit Hilfe der obigen Spracherweiterung einen generischen Kommandozeilenparser entwickeln, mit dem das Parsen von Kommandozeilenoptionen in einen Record-Typ ohne redundanten Code möglich ist.

Weiterlesen...

Optimierung von Haskellprogrammen - Teil 2

Im vorherigen Teil unserer Serie haben wir uns Optimierungen angeschaut, die durch das Erzwingen von Berechnungen und Typ-Annotationen das Speicherverhalten und die Laufzeit von Haskellprogrammen verbesserten. Um den Wahrheitsgehalt solcher Behauptungen zu überprüfen, messen wir einfach das Verhalten der Programme. Um aber auch die Auswirkungen der gemachten Veränderungen zu verstehen und sicher zu gehen, dass tatsächlich das passiert was passieren soll, müssen wir uns den vom Compiler generierten Code anschauen. Was bei Low-Level-Sprachen wie C und C++ Assemblercode und bei JVM-Spachen Java-Bytecode wäre, ist bei dem Glasgow Haskell Compiler (GHC) Core.

Weiterlesen...

Frege Tag in Basel: Haskell für die JVM

Freitag, den 11. September 2015 treffen sich alle, die an Haskell für die JVM interessiert sind, in den Räumlichkeiten von Canoo in Basel.

Weiterlesen...