Funktionale Programmierung mit Haskell
-
höhere programmiersprachen machen aus rekursionen intern oft schleifen.
Intern kennt der Computer keine Schleifen nur Spruenge. Jedoch mag tail code optimisation auf Assemblerebene wie Assembler von Schleifen aussehen, Aber Schleifen und Rekursion sind trotzdem verschiedene Konzepte. Iteration wird in Scheme trotzdem durch eine rekursive Notation ausgedrueckt.
-
knivil schrieb:
Intern kennt der Computer keine Schleifen nur Spruenge.
ich bitte dich. es gibt einige cpus instructions, die bei sprüngen automatisch irgendwelche register hoch/runterzählen oder sogar 'loop' heissen.
knivil schrieb:
Auch wird mein C++ Kompiler nie aus einer Rekursion eine Schleife machen.
sag niemals nie. wenn er's macht, merkst du jedenfalls nichts davon.
-
ja, schon der Z80 hatte einen Maschinenbefehl für Schleifen: DJNZ = "decrement and jump if not zero"
-
Ich finde, dass es keine Schleifen wie sie z.B. in Pseudocode, C++ oder anderen Programmiersprachen sind. Mittels Registeroperation+Jump erzwinge ich nicht die gleiche Semantik, da ich ueberall hinspringen kann. Es ist ist richtig, das Schleifen so auf Assemblerebene umgesetzt werden. Dass ist vielleicht kleinlich, aber (nur) meine Meinung.
sag niemals nie. wenn er's macht, merkst du jedenfalls nichts davon.
Bei inline vielleicht, aber bei allen anderen ... muss ich mal testen.
-
Bei inline vielleicht, aber bei allen anderen ... muss ich mal testen.
Klar. Tailrekursion. Aber schön mit -O kompilieren.
-
knivil schrieb:
Ich finde, dass es keine Schleifen wie sie z.B. in Pseudocode, C++ oder anderen Programmiersprachen sind. Mittels Registeroperation+Jump erzwinge ich nicht die gleiche Semantik, da ich ueberall hinspringen kann. Es ist ist richtig, das Schleifen so auf Assemblerebene umgesetzt werden. Dass ist vielleicht kleinlich, aber (nur) meine Meinung.
ich sehe das lockerer: 'ne schleife ist einfach das wiederholte ausführen eine code-abschnitts, bis eine abbruchbedingung auftritt (oder auch nicht). in dem sinn ist für mich: if (bedingung) goto dorthin; auch eine schleife.
-
Naja, dann ist alles eine Schleife, weil Recursion auch das wiederholte Ausfuehren von Code ist, bis eine Abbruchbedingung auftritt.
-
knivil schrieb:
Naja, dann ist alles eine Schleife, weil Recursion auch das wiederholte Ausfuehren von Code ist, bis eine Abbruchbedingung auftritt.
ok, 'ausgenommen rekursionen', hätte ich noch dazuschreiben müssen. ausserdem muss das 'goto' an eine stelle hüpfen, die irgendwie dafür sorgt, dass das programm auch wieder an dem selben goto vorbeikommt.
-
+fricky schrieb:
knivil schrieb:
Naja, dann ist alles eine Schleife, weil Recursion auch das wiederholte Ausfuehren von Code ist, bis eine Abbruchbedingung auftritt.
ok, 'ausgenommen rekursionen', hätte ich noch dazuschreiben müssen. ausserdem muss das 'goto' an eine stelle hüpfen, die irgendwie dafür sorgt, dass das programm auch wieder an dem selben goto vorbeikommt.
Sind Continuations dann auch Schleifen?
-
Mr. N schrieb:
Sind Continuations dann auch Schleifen?
nein, natürlich nicht. und threads bzw. tasks auch nicht, menno, du weisst doch genau, was ich meinte.
-
ProgChild schrieb:
Aber wenn man das mit den im Moment eingesetzten Script-Sprachen vergleicht, so gibt es da noch weitere Haskell-Compiler, die es an Performance locker mit den Script-Sprachen aufnehmen können. Ich schreibe das nur nochmal, weil ich finde, dass das "Microsoft-Argument" nun wirklich kein Argument gegen Haskell und den GHC ist.
Haskell ist keine Scriptsprache. Haskell ist sogar alles andere als eine Scriptsprache :). Und nur weil es andere gibt die schlechter sind, sollte man sich doch nicht auch mit etwas schlechterem zufrieden geben. Und bevor sich irgendwer angegriffen fühlt, das soll nicht gegen irgend eine andere Sprache gehen, sondern ein "pro guter Compiler" Argument sein :).
@ProgChild, ich hab dir doch eine ganze Reihe Quellen dazu geschrieben. Was hätteste denn noch gerne?
-
wird der Nachfolger Haskell' eigentlich unveränderten Haskell-98-Code compilieren ?
Und wieso gibt es so wenige real-world applications in Haskell ? - die meisten Anwendungen scheinen eher für die theoretische Informatik interessant zu sein.
-
u_ser-l schrieb:
wird der Nachfolger Haskell' eigentlich unveränderten Haskell-98-Code compilieren ?
Und wieso gibt es so wenige real-world applications in Haskell ? - die meisten Anwendungen scheinen eher für die theoretische Informatik interessant zu sein.
Hmm, also die Compiler setzen alle mehr oder weniger gut den Haskell-98 Standard um. Alles was darüber hinaus geht wird über sogenannte Extensions dazugepackt. Wenn du z.B. die Monomorphismenrestriktion loswerdenwillst, kannst du das im ghc mittels Compilerflag -XNoMonomorphismRestriction, oder durch markieren in der Datei, bekommen.
Zu der real world geschichte, ich hab vor mir ein ganzes Buch liegen (Real World Haskell), dass sich mit real world applications auseinandersetzt.
(Das gibts übrigens auch im Netz: http://www.realworldhaskell.org) Und wenne inner Wikipedia so ne schöne latex-Formel siehst, dann steckt da auch Haskellsoftware dahinter.
-
frosch03 schrieb:
@ProgChild, ich hab dir doch eine ganze Reihe Quellen dazu geschrieben. Was hätteste denn noch gerne?
Nein. Hast du nicht. Du hast lediglich auf die Publikations-Stellen hingewiesen, wo man die Behauptungen angeblich nachprüfen kann. Ich kann allerdings schlecht all diese Zeitschriften bzw. alle Paper lesen.
-
ProgChild schrieb:
Nein. Hast du nicht. Du hast lediglich auf die Publikations-Stellen hingewiesen, wo man die Behauptungen angeblich nachprüfen kann. Ich kann allerdings schlecht all diese Zeitschriften bzw. alle Paper lesen.
Stellt sich die Frage, warum du dann noch nach Quellen frägst, wenn du gleich mal ausschließt, diese lesen zu können. Naja und meine Quellen setzen nunmal voraus, dass man sie liest.
(Wobei ich hätte da auch ein paar Videos, wenn dir das helfen würde)Aber im Ernst jetzt, was erwartest du denn. Selbst wenn ich dir jetzt eine Bildschirmseite voller Links gebe um dich zu beeindrucken, nutzt dir das doch recht wenig. Denn woher weißt du, ob da überhaupt etwas sinnvolles drin steht? Oder währ dir das egal? So oder so, wenn du wirklich Quellen hinterfragen willst, kommst du ums lesen derselben nicht drum rum.
-
also gut, zugegeben, Haskell hat schon was. Auch wenn es auf den ersten Blick ein wenig nach Hieroglyphen einer außerirdischen Intelligenz aussieht
Grundsätzlich: weshalb sollte man Haskell nehmen und nicht Scheme oder eine Sprache aus der ML-Reihe, zB SML oder OCaML ??
-
ProgChild schrieb:
Das ist natürlich nicht einfach und muss gelernt werden. Die Frage ist halt, wenn du das formulieren kannst, welche der beiden Varianten direkter deine Überlegungen in Quelltext gießen. Dass das erst gelernt werden muss, steht außer Frage. Ich behaupte nur, dass sich das lohnt, eben weil unsere Denkweise nicht prozedural ist. Und obwohl wir es vielleicht gewohnt sind, gewisse Lösungen prozedural zu formulieren.
Du behauptest, die menschliche Denkweise sei nicht prozedural und der andere behauptet, sie sei prozedural. Solange ihr keine empirischen Untersuchungen zu exakt dieser Frage vorweisen könnt, ist es doch völlig sinnlos, sich darüber zu streiten. Ich persönlich würde die Fragestellung zwar so oder so als reduktionistisch-lächerlich betrachten, aber das ist ein anderes Thema. Wo wir uns jedoch wohl einigen können, ist, dass wir es in der Tat gewohnt sind, gewisse Lösungen prozedural zu formulieren. Ich würde aber sogar behaupten, dass alle Lösungen prozedural gefunden werden. Rekursion wäre dann lediglich ein handlicher Formalismus, mit dem man das Verfahren abstrahieren und kompakt im Gedächtnis abspeichern kann.
-
Die Frage aller Fragen ... schwer als Anfaenger zu beurteilen. Fuer Scheme gibt es z.B. "Struktur und Interpretation von Computerprogrammen" (die Videolektures kann ich nur empfehlen) und viele andere Quellen. Falls man selbst einen Interpreter schreiben moechte, kann man sich fuer den Anfang Minischeme oder Tinyscheme (grauenhafter Code) ansehen. Es gibt aber auch genug Buecher dazu. Jedoch wird Funktionale Programmierung erstmal nicht so explizit hervorgehoben. Wie es bei Haskell oder ML aussieht, weiss ich nicht.
Ich würde aber sogar behaupten, dass alle Lösungen prozedural gefunden werden.
Die Mathematik hat mich eines besseren belehrt. Kreativitaet laesst sich schwer prozedural ausdruecken (und waere dann wohl nicht mehr als Kreativitaet zu betrachten).
-
knivil schrieb:
Die Mathematik hat mich eines besseren belehrt. Kreativitaet laesst sich schwer prozedural ausdruecken (und waere dann wohl nicht mehr als Kreativitaet zu betrachten).
Was verstehst du unter Kreativität und wieso ist dies mit Rekursion, nicht aber prozedural möglich? Kann es sein, dass Kreativität für dich etwas ist, was nicht explizit ausbuchstabiert dort stehen darf, sondern implizite Schritte umfassen muss, die nur immateriell im Geiste herumschweben dürfen? Bei einem solchen Verständnis wäre Rekursion natürlich kreativer. Wie gesagt, Rekursion befindet sich eine Abstraktionsstufe höher. Doch mein Verständnis von Kreativität ist das nicht.
-
Irgendwie gehts langsam am Thema vorbei: Funktionale Programmierung vs. Prozedurale. Rekursion kann ich auch mit Prozeduren machen. Es ging um Prozeduren als natuerlicher Ansatz um Probleme zu loesen. Damit kann man aber manchmal schwerlich Problemloesungsstrategien entwickeln. Aussderm habe ich nie behauptet, dass Kreativitaet irgendwas mit Rekursion zu tun haette.