spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hey,
ich "muss" in der Uni in einem Kurs mit Haskell arbeiten. Nun, funktional ist glaube ich nicht ganz meine Welt, wobei ich mich mittlerweile immer besser in die Denkensweise einarbeiten kann. hauptsächlich lerne ich mit dem Buch "Programming in Haskell" von Graham Hutton, welches auf dem Gebiet ja zu den Standardwerken zählt. Ich versuche mich grad in Parser einzuarbeiten, da dass das nächste Thema ist, was ansteht. Dazu wird im Buch erst folgendes erstellt:



Es wird also ein Typ für Parser a festgelegt, welcher eine Liste mit Tupeln von a und Strings ausgibt. Gedacht ist es so, dass wenn ein Parser fehlschlägt, die leere Liste zurück gegeben wird. Im Normalfall, enthält die Liste ein Element, und für den Fall, dass der String auf verschiedene Möglichkeiten verarbeitet werden kann, kann man nun die verschiedenen Varianten in der Liste ausgeben. Soweit so gut.
Es werden dann ein paar Standardparser erstellt.
return schlägt nie fehl, und gibt den Parameter als result zurück. Der übergebene String (Siehe Lambda) wird im Tupel an 2ter Stelle zurückgegeben. Diese 2te Stelle ist dafür gedacht, einen Reststring zurück zu geben, falls nicht der ganze String vom Parser verarbeitet werden kann.
failure schlägt immer fehl und gibt die leere Liste zurück.
item schlägt mit leeren Strings fehl, gibt ansonsten das erste Zeichen als result zurück.
Die Funktion parse ist einfach nur als Hilfsfunktion gedacht, damit man die einzelnen Parser "einfacher" testen kann. Quasi sowas wie parse (return 1) "abc" was dann [(1, "abc")] zurück geben sollte.

Bis hier hin ist alles soweit klar, wobei er sich bei mir beschwert, wenn ich return aufrufen will, da return ja schon definiert ist. Finde ich schon merkwürdig dass es dann so in das Buch aufgenommen wird, aber zum testen habe ich die Funktion dann einfach in preturn umbenannt, für parser-return. Dann klappts auch soweit.

>>= ist als Operator für sequencing gedacht, damit man die einzelnen Parser hintereinander schalten kann. Hier wird wirds jetzt komisch.
Es wird ein Testparser erstellt:


Das Prinzip dahinter ist mir soweit klar. Trotzdem finde ich es merkwürdig, dass ein Operator für sequencing erstellt wird und dann nicht genutzt wird. Wäre ja soweit kein Problem, doch er meckert.

Die Fehlermeldung:
No instance for (Monad ((-)) String))
arising from a use of 'return'
Als mögliche Korrektur wird mir vorgeschlagen, eine Deklaration für (Monat ((-)) String)) anzugeben.
Von Monaden stand bis jetzt noch nichts im Buch. Deshalb gehe ich davon aus, dass man hier für keine Monaden braucht. Sehe ich das richtig? Monaden werden weiter hinten im Buch zwar behandelt, aber es macht ja keinen Sinn, da in den Codestücken keine Monaden definiert wurden.

Nun geht das überhaupt ohne Monaden? Soweit ich weiß sind diese ja dafür da Funktionen nacheinander aufzurufen, von daher wäre das hier ja eigentlich ein Einsatzgebiet dafür. In der Vorlesung sind Parser jedoch auch vor Monaden geplant, von daher denke ich, dass es auch ohne gehen müsste. Kennt jemand eine Lösung für das Problem, oder geht das wirklich nur mit Monaden?

Hey,
vielen Dank für den langen Beitrag. Hat mir schon mal weitergeholfen. Muss mich aber auch entschuldigen Hab in dem Kapitel mal weiter gelesen. Am Ende kommt der Verweis, dass mit Monaden gearbeitet werden muss. Komisch, dass er da Themen vorweg greift, und dann nicht mal die korrekte Implementation zeigt aber gut Die Logik der Parser habe ich soweit erst mal verstanden. Werde mir die Themen jetzt einfach weiter vornehmen. Parallel arbeite ich "Real World Haskell" durch. Hatte es vorher schon im Netz gefunden und bin wirklich glücklich damit. Vieles wird unglaublich viel besser erklärt als bei Graham Hutton. Kann man wirklich super mit arbeiten. Hinzu kommt, dass mir die Einteilung der einzelnen Kapitel eher zusagt. Die gewählten Beispiele machen dann natürlich auch einiges her, da sie weniger abstrakt sind. Sind halt nicht nur "sinnfreie" Aufgaben, sondern Sachen die man auch mal Anwenden kann.
Werde mir deinen geposteten Code noch mal genauer anschauen wenn ich zu Hause bin. So auf die Schnelle konnte ich noch nicht alles 100% nachvollziehen aber das krieg ich schon hin
Also nochmals vielen Dank.

Habe jetzt heute im Zug ein bisschen weiter im Buch gelesen. Mittlerweile gefällt mir Graham Hutton immer weniger. In Real World Haskell wird einfach unglaublich viel besser auf Einzelheiten eingegangen. Was mir aufgefallen ist, ist dass die Implementierungen oft ineffizient sind. Oft werden Funktionen benutzt, die das Problem zwar lösen, aber viel mehr tun als sie müssten. Das ist mir jedoch auch bei Implementierungen verschiedener Algorithmen in Haskell im Netz aufgefallen. Als Beispiel wird ein Element aus einer Liste gesucht. Dabei wird oft die Liste komplett gefiltert. Dabei wird dann jedoch die ganze Liste durchlaufen. Persönlich würde ich mir eine Funktion schreiben, die abbricht, sobald das Element gefunden wurde. Jetzt hat ja jede Sprache ihren eigenen Stil. Haskell ist ja jetzt auch nicht unbedingt die Sprache, die versucht etwas besonders effizient zu lösen. Ist es einfach so, dass man mit Haskell versucht eine Lösung zu finden, obwohl es vielleicht effizienter geht? Klar sollte man versuchen, sein Problem möglichst gut zu lösen, aber ist es vielleicht in der Haskell-Gemeinschaft einfach so, dass man auf bereits implementierte Funktionen zurück greift und so sein Problem löst, oder ist es schon so, dass man bestimmte Funktionen neu schreibt, um es etwas schneller zu lösen?
Ich finde es schwierig das Problem grad besser zu beschreiben. Dabei geht es mir eher um die Philosophie von Haskell. Würde dazu gerne etwas mehr erfahren. Ich muss sagen, dass mir die Sprache und das Prinzip hinter Funktionaler Programmierung immer besser gefällt, da es schon einige Vorteile hat. Aber mir fehlt es halt immer noch stark an Erfahrung.