Haskell vs Lisp vs Scheme etc für KI usw
-
ohne nun mit lisp oder haskell übermäßig viel gearbeitet zu haben, kann ich doch sagen, dass bei sprachen grundverschieden sind, auch wenn sie unter dem label "funktional" laufen.
ich glaube, der witz bei lisp ist vorallem, dass man mit lisp - code (sehr vereinfacht gesprochen) wie mit strings umgehen kann, soll heissen, man kann programmcode während der laufzeit automatisch generieren, ändern etc. - und eben auch ausführen lassen. aus dem bauch heraus würde ich sagen, dass das für KI sachen durchaus nützlich sein könnte..
-
lisp ist imho die reinere sprache, von der syntax her. lisp ist reine baumstruktur, reiner code. deswegen kann ein lisp programm auch lisp programme schreiben, die wiederum lisp programme schreiben koennten.
Was erzählst du da eigentlich? Was soll den "unreiner" Code sein? Ich kann dir auch ein Java Programm schreiben, das ein Java Programm schreibt usw....
Meinst du vielleicht das Lisp eine echte funktionale Sprache ist? Also ohne Gedächniss und Seiteneffekten?
-
DEvent schrieb:
Ich kann dir auch ein Java Programm schreiben, das ein Java Programm schreibt usw....
und ich kann mit einem stein eine schraube in die wand hämmern.
-
Doktor Prokt schrieb:
Haskell ist natuerlich auch nicht rein bzw. "komplett" funktional. Das ist aber nicht schlimm, dass das so ist (zum Glueck).
Abgesehen von den Funktionen mit "unsafe"-Prefix ist Haskell tatsächlich rein funktional, sprich völlig seiteneffektfrei; oder ich habe Haskell grundlegend falsch verstanden. Selbst Ein/Ausgabe wie getLine/putStrLn wird über Datenabhängigkeiten dargestellt, nicht über Seiteneffekte.
Dass der Compiler den Haskell-Code zwangsläufig in imperativen Maschinen-Code transformiert, ist ein anderer Punkt. Auf Haskell-Ebene ist der Code meines Wissens nach jedoch immer seiteneffektfrei (von den "bösen" unsafe-Funktionen abgesehen, die nur äußerst selten gebraucht werden, und AFAIK auch dann nur um bestimmte Komplexitätsklassen zu erreichen). Eine Funktion wie "getLine" liefert zum Beispiel bei jedem Aufruf dasselbe Objekt zurück; das ist der Grund warum getLine nicht einfach einen String liefern kann.
-
DEvent schrieb:
Meinst du vielleicht das Lisp eine echte funktionale Sprache ist? Also ohne Gedächniss und Seiteneffekten?
Das Lisp keine "echte funktionale" Sprache ist, hatten wir doch schon erwähnt? Nicht?
Ansonsten fällt es sicher schwer Lisp ohne Lisp Kenntnisse zu bewerten und wie groß sind bitte deine Lisp-Kenntnisse?
-
Christoph schrieb:
Dass der Compiler den Haskell-Code zwangsläufig in imperativen Maschinen-Code transformiert, ist ein anderer Punkt.
Jo, darauf wollte ich auch nicht abzielen, ganz so kleinlich bin ich dann doch nicht
Ich sehe ein Problem bei der IO Monad. Wenn zum Beispiel eine hypothetische Funktion getLine ein IO String zurueckgibt, so gibt es sehrwohl viele Werte, welche eben diesen Typ haben.
-
Doktor Prokt schrieb:
Christoph schrieb:
Dass der Compiler den Haskell-Code zwangsläufig in imperativen Maschinen-Code transformiert, ist ein anderer Punkt.
Jo, darauf wollte ich auch nicht abzielen, ganz so kleinlich bin ich dann doch nicht
Ich sehe ein Problem bei der IO Monad. Wenn zum Beispiel eine hypothetische Funktion getLine ein IO String zurueckgibt, so gibt es sehrwohl viele Werte, welche eben diesen Typ haben.
Nein, getLine liefert aus Haskell-Sicht immer dasselbe Objekt zurück. Das kann man z.B. daran sehen, dass du sowas schreiben kannst wie
myGetLine = getLineund dann im folgenden myGetLine anstelle getLine benutzt.
getLine liefert ein anderes "IO String"-Objekt als z.B. die Funktion hGetContents, was den ganzen verfügbaren Eingabe-Stream als IO String liefert.In Haskell sind Funktionen mit null Parametern automatisch konstante Werte.
Das IO String-Objekt von getLine kann man auch als Handle betrachten. Das stdin-Handle ist z.B. immer identisch, ebenso wie eben der Rückgabewert von getLine. Nur wenn man etwas damit anfängt, wird zusätzliche Status-Information gebraucht, die implizit im IO Monad steckt. Das State-Monad zeigt sehr schön, wie man diese Statusinformation verstecken und nutzen kann; das State Monad lässt sich mit wenigen (seiteneffektfreien!) Zeilen komplett in Haskell implementieren.
-
DEvent schrieb:
Was erzählst du da eigentlich? Was soll den "unreiner" Code sein?
hab ich doch geschrieben: die syntax, naemlich keine. nur baumstruktur. alles einheitlich.
wenns nur ein problem mit meiner aussprache oder deinen loeffeln waere, aber nein, es sind deine augen
-
@Christoph: Ich habe noch nicht so viel Ahnung von Monaden und bei der State-Monad sehe ich ein, dass diese rein funktional ist.
Auch bei der Eingabe faellt mir keine geeignete Argumentation ein, wohl aber bei der Ausgabe.
Zum Beispiel gibt ja auch die Funktion putStrLn immer den gleichen Wert zurueck, keine Frage, aber sie veraendert doch die "Welt" (es wird auf stdout geschrieben). Wie ist das mit dem "rein" funktionalen Gedanken vereinbar?
-
Doktor Prokt schrieb:
Zum Beispiel gibt ja auch die Funktion putStrLn immer den gleichen Wert zurueck, keine Frage, aber sie veraendert doch die "Welt" (es wird auf stdout geschrieben). Wie ist das mit dem "rein" funktionalen Gedanken vereinbar?
Die "Welt" ist in gewisser Weise ein Parameter und wird herumgereicht. putStrLn nimmt nicht nur einen String, sondern auch die aktuelle "Welt" und liefert die neue "Welt" zurück. getLine nimmt die aktuelle "Welt" und liefert einen String und eine neue "Welt" zurück.
-
Zur Frage, warum alle immer Lisp empfehlen:
Ist ja ganz logisch. Wir sind ja auch in Lisp geschrieben...
Beweis:
-
zum mitsingen: http://www.gnu.org/fun/jokes/eternal-flame.html