Diskussion:Haskell (Programmiersprache)

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Haskell (Programmiersprache)“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Verwendung

Gibt es eine spezielle Verwendung? Auf welchen Systemen wird diese Sprache verwendet. Ich würde gern ein wenig mehr über die Sprache an sich erfahren; die Beispiele nützen mir leider wenig, ich weiss ja nicht, warum die Befehle so aussehen. Bin allerdings auch Computeridiot :-) --Joh3.16 17:40, 13. Apr 2004 (CEST)

Hm, was genau willst du denn noch erfahren? Ein Tutorial zu Haskell wäre hier sicher fehl am Platze, da verweise ich z.B. auf http://www.s-inf.de wo es ein Tutorial von mir zu Haskell gibt, oder auch die ganzen anderen Links hier. All zu komplexe Beispiele haben hier auch nichts zu suchen. Ich werde mal schauen ob ich etwas zu den grundlegenen Techniken schreiben kann ;-) --Prometeus 18:40, 8. Apr 2005 (CEST)

Haskell ist funktional, d.h. der Blick fällt sofort auf die zu grunde gelegt Algorithmen. Man sieht eigentlich nur die mathematische Funktion - das IST das Programm. Spezielle Verwendung: Forschung und Lehre (teilweise in Informatik-Leistungskursen, öfter an Hochschulen), von kommerziellem Erfolg habe ich jedoch noch nichts vernommen. --Kosmix 01:19, 2. Dez. 2006 (CET)

Siehe beispielsweise http://www.haskell.org/haskellwiki/Haskell_in_industry --Plaicy 02:37, 4. Mär. 2007 (CET)

Werbung für Programmiersprachen auf Wikipedia

Ziel von wikipedia ist es möglichst sachliche und unvoreingenomme Informationen bereit zu stelllen. Allerdings ist es durchaus nicht unüblich, dass ein bischen Werbung für eine Sache gemacht wird.

z.b. beginnt der Artikel über Python folgender massen:

"Python wurde mit dem Ziel entworfen, möglichst einfach und übersichtlich zu sein. Dies wird durch zwei Dinge erreicht:..."

Im Gegensatz dazu beginnt der Haskell-Artikel mit:

"Gegen Ende der 1980er Jahre gab es bereits einige funktionale Programmiersprachen, alle mit ihren Vor- und Nachteilen...."

Wer sich die Mühe macht einen Artikel zu bearbeiten ist in den meisten Fällen nicht wirklich neutral..

Ich finde man sollte den Anfang des Artikels umformulieren und die Vorteile von Haskell gleich am Anfang deutlich herausstellen. Die Ziele und Designkrieterien von Haskell sind wichtig um die Aspekte die später erklaert werden zu verstehen.

man könnte das so ähnlich formulieren:

Die Designer von Haskell verfolgen unter anderem folgende Ziele: 1) Die Definition der Sprache ist gleichzeitig einfach und exakt. (-> formale semantik) 2) Man kann mit mathematischen Methoden zeigen, dass ein Haskell-Programm korrekt ist. 3) Viele Arten von Programmierfehler werden prinziell ausgeschlossen. (-> typesystem) 4) Haskell kann für alle Aufgaben eingesetzt werden, für die z.b. auch Java oder Python benutzt wird. 5) Haskell Programme lassen sich gut parallelisieren.

An der Weiterentwicklung von Haskell wird an vielen Universitäten intensiv geforscht. Gleichzeitig gibt es schon einen festen Sprachstandard und ausgereifte Compiler für Haskell.

Sehr viele Besucher der Seite werden eh nur die ersten Sätze lesen. Obwohl der Wiki-Artikel sehr gut geschrieben ist, glaub ich nicht, dass viele Leser ohne Vorkenntnisse in funktionaler Programmierung (selbst Informatiker oder Java Programmierer) wirklich versehen was gemeint ist.

Oft bleibt bei Haskell nur haengen was es alles nicht gibt (z.b. keine Zuweisungen) Dass dies kein Mangel ist, sondern durchaus gewollt, und dass viele Sachen in Haskell auch ohne Zuweisungen viel besser funktionieren (weil es z.b. andere Konzepte gibt) wird oft nicht klar.

Allerdings sollte man auch nicht verschweigen, dass Haskell eine ganz normale Programmiersprache ist, in der man fast alle Hacks machen kann, die es in anderen Sprachen gibt. Haskell kann man z.b. durchaus auch zur Skript-Programmierung benutzen.

--134.99.112.66 22:19, 10. Apr. 2008 (CEST)

anscheinend beziehst du dich auf eine andere als die aktuelle version des artikels, denn diese beginnt mit: Haskell ist eine rein funktionale Programmiersprache, benannt nach dem .... die geschichte der entwicklung von haskell beginnt mit dem von dir zitierten text. dort, wo geschichte drin ist, soll auch geschichte stehen und nichts über das, was toll ist oder auch nicht. dafür gibt es ja die eigenschaften, und wenn das aus deiner sicht nicht ausreicht, dann schreib doch bitte einen ansatz zu den vor- und nachteilen. gruss --Murkel ^(anmurkeln) 21:04, 10. Apr. 2008 (CEST)

zunächst etwas grundsätzliches: um eine diskussion zu führen, solltest du deine zuvor gemachten beiträge im nachhinein nicht mehr verändern oder erweitern. ein aussenstehender kann dem gesprächsverlauf so nicht folgen. weiterhin fällt es mir nun schwer, meine antwort korrekt und sinnvoll zu platzieren.

zu deiner aufzählung: mir ist nicht bekannt, dass diese fünf punkte die intention zur entwicklung von haskell gaben (hast du belege?). dies würde ich sogar bezweifeln. vor haskell gab es schon andere funktionale sprachen; warum das rad neu erfinden? diese eigenschaften sind auch nicht haskellspezifisch sondern merkmale aller funktionalen programmiersprachen; bei (4) bin ich mir nicht ganz sicher.

weitere von dir angeführte punkte sind zu allgemein oder sind bereits eingearbeitet worden.

• An der Weiterentwicklung von Haskell wird an vielen Universitäten intensiv geforscht
• ...dass Haskell eine ganz normale Programmiersprache ist, in der man fast alle Hacks machen kann...
• Gleichzeitig gibt es schon einen festen Sprachstandard und ausgereifte Compiler für Haskell.

wikipedia soll als enzyklopädie aufgebaut werden und daher kurz und prägnant sein.

dein argument, es gäbe zuviele Eigenschaften, die haskell nicht habe, beurteilst du falsch. So sind Es gibt keine Unterscheidung zwischen Identität und Gleichwertigkeit von Objekten. und Das Fehlen von Nebenwirkungen vereinfacht es beträchtlich, Programmbeweise zu führen. keine nachteile sondern vorteile.

wikipedia ist eine enzyklopädie und bietet daher überblickshaft wissen. wer sich mit dem thema tiefergehend auseinandersetzen möchte, wird anderweitig informationen suchen müssen. ob nun gewisse berufsgruppen den artikel verstehen oder nicht, kannst du sicherlich nicht pauschal beurteilen. schliesslich wirkten an diesem artikel sehr viele wikipedianer mit - das garantiert eine grundlegende verständlichkeit.

gruss --Murkel ^(anmurkeln) 21:31, 12. Apr. 2008 (CEST)

Effizienter Quicksort

Der Absatz "Diese Quicksort-Implementierung ist allerdings sehr ineffizient: Das Kopieren und Verlinken vieler kleiner Listen sorgt für eine durchschnittliche asymptotische Laufzeit von $O(n^{2})$. Natürlich kann man den Algorithmus aber auch mit der für Quicksort üblichen Laufzeit von $O(n\cdot \log n)$ implementieren." haut nicht hin. In der Tat braucht xs ++ ys $O(length\ xs)$ viele Operationen, aber das interessiert die $O(n\cdot \log n)$ von qsort nicht: Sei $T(n)$ die durchschnittliche Anzahl von Operation für ein qsort (xs mit Länge n). Dann gilt im günstigen Fall:

 T(0) = 0
 T(n) = n            -- die ganze Liste aufteilen nach <x und >=x
        + 2*T(n/2)   -- Teile sortieren
        + n/2        -- Lauzeit der ++

Dann ist immer noch $T(n)=O(n\cdot \log n)$.

Die Implementierung von Sth ist dennoch effizienter, denn die $n/2$ am Ende fallen weg. Juckt halt nur den konstanten Faktor im $O$. Im Prinzip verwendet Sth eine Differenz-Liste, i.e.

 type DiffList a = [a] -> [a]
 append f g      = f . g
 fromList xs     = \x -> xs ++ x
 closeDiffList f = f []

und dann halt

 qsort' :: [Int] -> DiffList Int
 qsort' = ... -- eben append statt ++
 qsort = closeDiffList . qsort'

-- anonym 7. Sep 2005 (CEST)

Eine effizientere Implementierung von Quicksort wäre:

   qsort' []     cs = cs
   qsort' (x:xs) cs = qsort' [y | y <- xs, y < x] (x : qsort' [y | y <- xs, y >= x] cs)
   
   qsort as = qsort' as []

Allerdings ist das wohl (besonders ohne Kenntnisse der Sprache) nicht mehr so leicht zu verstehen wie die im Artikel angegebene ineffiziente Implementierung. Sollte man es trotzdem dort noch einfügen? Oder lieber ein ganz anderes Beispiel suchen? Sth 14:59, 17. Okt 2004 (CEST)

Wuerde fuer ein anderes Beispiel plädieren. Eine Implementierung, die nur schön aussieht, aber eingentlich ineffizient ist, wird Haskell nicht gerecht. Man sollte das allgemeine Vorurteil, dass Haskell langsam ist nicht unnötig unterstützen. --134.99.112.66 22:19, 10. Apr. 2008 (CEST)

Francis Haskell

Sollte man fuer den Link auf Francis Haskell nicht eher eine Unterscheidungsseite unter Haskell einrichten, statt in Haskell (Programmiersprache) darauf zu verweisen? fs 01:20, 18. Dez 2004 (CET)

Python?

"Sprachkonstrukte aus Haskell wurden auch in die Programmiersprache Python übernommen." Welche? Was hat das für eine Bedeutung? --Glasreiniger 13:30, 16. Jun 2005 (CEST)

Antwort: Ähnlichkeiten zu Python bestehen darin, dass die Blockzugehoerigkeit von Codefragmenten durch die Einrückung bestimmt wird. Ähnlichkeiten bestehen durch dien einfache Handhabung mit Iteratoren; sie ermöglichen ähnliche Konstrukte, wie die lazy evaluation. Die referenzielle Tranzparenz ist aber nicht gegeben. Und Python ist nicht so Datentypsicher, wie Haskell.

Darüberhinaus sollte die starke verwandtschaft mit Ocaml genannt werden und von Prolog übernommene Techniken, wie zb. im fac -Beispiel gezeigt.

fac 0 = 1
fac n = n * fac (n - 1)

Auf Prolog bezogen würde man 'fac' Prädikat nennen und die beiden Zeilen sind die Regeln, die per Backtracking abgearbeitet werden.

So Aug 7 16:50:53 CEST 2005

Liegen die Ähnlichkeiten in der Natur der Sache, oder wurden Sprachkonstrukte in der einen oder anderen Richtung übernommen? Im ersteren Fall halte ich die Erwähnung für wenig hilfreich. --Glasreiniger 10:28, 10. Aug 2005 (CEST)

List comprehensions (wie auch immer die auf Deutsch heißen) kommen aus Haskell. Also

squares as = [x*x | x <- as]                -- Haskell
def squares(as): return [x*x for x in as]   #  Python

und evt. die Syntax für Lambdafunktionen

square = \x -> x*x       -- Haskell
square = lambda x: x*x   #  Python

sowie die verschiedenen eingebauten funktionalen Tools in Python (map, filter, reduce) --Sth 02:26, 15. Dez 2005 (CET)

Anmerkung dazu am: Fr Aug 31 16:05:02 CEST 2007: Auch, wenn in beiden Beispielen das Ergebnis im wesentlichen dasselbe ist, verläuft die Abarbeitung der Listen zwischen Haskell und Python sehr unterschiedlich. In Python hat eine Liste während der Abarbeitung ( derer durch ein Iteratorkonstrukt zb) immer eine feste Länge - in Haskell kann man sich unter einer Liste im Prinzip schon einen Iterator vorstellen, der die Listenelemente liefert und während der Abarbeitung länger werden kann. Somit ist es für die Haskell-Variante möglich, die Ergebnisse der Operation auf die Listenelemente bereits auszugeben, während die Berechnung für alle Listenelemente noch nicht abgeschlossen ist. Das im Artikel gezeigte Beispiel für die Fibonaccy-Liste zeigt dies:

fibs :: [Integer]
fibs = 0 : 1 : (zipWith (+) fibs (tail fibs))

Der Rueckgabewert von fibs wird somit permanent laenger und kann bereits ausgegeben werden - in Python braeuchte man, um dies genauso zu implementieren, zumindest eine Bedingung für einen Abbruch der Rekursion und haette dann auch nur eine begrenzt lange Liste.

Quicksort? Oder eher Mergesort?

Wenn generell das mittlere Element als Pivotelement gewählt wird, wäre es nicht korrekt den Algorithmus mit Mergesort zu benennen?

Nein!

Hi! Bei dem angegebenen Programmstück wird das erste Element ("x") der unsortierten Liste als "Kriterium" gewählt, danach wird die Liste in der Form {kleiner als x}{x selbst}{größergleich x} wieder zusammengefügt, nachdem die linke und rechte Teilmenge ihrerseits (rekursiv) durch Quicksort sortiert wurde. x muss dabei nicht notwendigerweise mittig liegen, es kann auch irgendwo am Rand liegen, es war nur zufällig am Anfang der unsortierten Liste. Bei Mergesort funktioniert das ganze so, dass die zu sortierenden Daten (weil sie nicht auf einmal in den Hauptspeicher passen) in zwei oder mehrere Pakete aufgeteilt werden, die dann jeweils für sich (mit einem anderen Sortierverfahren) sortiert werden. Danach werden die einzelnen, sortierten Stapel im Reißverschlussverfahren wieder zu einem vereinigt. Also haben wir hier keine Rekursion. Die Sortierverfahren unterscheiden sich fundamental. Hoffe, das war einigermaßen verständlich? --Kurt seebauer 23:53, 16. Nov 2005 (CET)

List notation

 [ x | x>1 , mod x 2 == 0]

Welcher Haskell-Interpreter/Compiler kann das? Also hugs und ghci scheinen das nicht zu mögen.

[ x | x<-[1..] , mod x 2 == 0]

funktioniert. Oder kürzer

[2,4..]

--Plaicy 13:14, 16. Feb 2006 (CET)

ich habe die beispiele reingestellt und war anscheinend etwas ungenau. ein vergleich durch x>1 funktioniert schon, aber die Angabe des Argumentbereichs x<-[1..] fehlt oder anders ausgedrückt x kann nicht instanziiert werden, da keine aussage zum wertebereich vorliegt (siehe bsp quicksort). gruß --Murkel ^(anmurkeln) 23:05, 16. Feb 2006 (CET)

Jetzt hat jemand den ersten Vorschlag übernommen. Dann hat sich das wohl erledigt.--Plaicy 16:36, 4. Mär 2006 (CET)

Praxiseinsatz?

Schöner Artikel, aber praktisch nur Theorie... Wie wäre es, noch ein paar Infos hinzuzufügen, wo, wozu, von wem Hashkell denn eingesetzt wird? Oder ist es ein reines akademisches Spielzeug? Dann kann man auch das schreiben.--212.203.86.162 13:30, 1. Mär 2006 (CET)

Siehe http://www.haskell.org/haskellwiki/Haskell_in_practice. Laut http://www.haskell.org/communities/05-2002/html/report.html wird/wurde Haskell außerdem von xilinx eingesetzt.--Plaicy 01:56, 5. Mär 2006 (CET)

Beispiele

Ist dieses "Listen teilen"-Beispiel wirklich sinnvoll? Das ließe sich ja auch einfacher als

halb as = splitAt (length as `div` 2) as

schreiben und mir ist nicht klar, wozu dieses Beispiel da überhaupt gut sein soll.(Vorstehender nicht signierter Beitrag stammt von Sth (Diskussion • Beiträge) 13. Jan. 2007, 00:09)

Ich wäre auch eher für löschen. Zu mindest das die Funktion "rest" sollte man sich IMHO sparen. Ob nun beim dividieren auf oder abgerundet wird ist ja von Prinzip ziemlich egal.--Plaicy 01:09, 22. Jan. 2007 (CET)

Redundanzen mit anderen Artikeln

Beim Lesen des Artikels waren mir die vielen Auflistungen unangenehm aufgefallen. Beim Versuch, den Abschnitt "Programmfluss" dahingehend zu überarbeiten war mir dann aufgefallen, dass vieles in diesem und den nachfolgenden Abschnitten redundant zu anderen Artikeln ist, namentlich die Erklärungen von funktionaler Programmierung, Bedarfsauswertung und Nebenwirkungsfreiheit. Das ist natürlich an sich kein Kritikpunkt und für eine geschlossene Beschreibung von Haskell auch notwendig, hat aber in meinem Fall den Lesefluss etwas gestört. Beim Versuch, diese Redundanzen zu verringern, ist mir der Abschnitt dann auf etwa ein Viertel zusammengeschnurrt, und da habe ich dann kalte Füße bekommen. Hier zum Vergleich die beiden Fassungen des Abschnitts:

Vorher:

• Haskell ist eine rein funktionale Programmiersprache. Funktionen haben keine Nebenwirkungen. Das heißt, von einer Funktion, die Werte vom Typ A verarbeitet und Ergebnisse vom Typ B bereitstellt, kann man sicher sein, dass sie ausschließlich das tut und nicht mehr. Wenn eine Funktion an verschiedenen Stellen im Programm auf den gleichen Wert angewendet wird, kommt immer das gleiche Ergebnis heraus. Funktionale Programmierung unterscheidet sich von der Benutzung von Funktionen in imperativen Sprachen dadurch, dass die Reihenfolge der Berechnungen vom Programmierer nicht angegeben werden muss. Der Programmierer beschreibt lediglich Abhängigkeiten von Daten und der Übersetzer legt die Abarbeitungsreihenfolge auf einem imperativ arbeitenden Rechner selbstständig fest.

• Es gibt keine imperativen Sprachkonstrukte. Durch Monaden ist es möglich, Ein- und Ausgabeoperationen und zustandsabhängige Berechnungen wie Zufallsgeneratoren rein funktional zu behandeln.

• Es gibt keine Operationen, die einen Variablenwert verändern. So gibt es auch keine Unterscheidung zwischen Variablen und Konstanten und man braucht keine const-Attribute wie in C.

• Es gibt keine Unterscheidung zwischen Identität und Gleichwertigkeit von Objekten.

• Das Fehlen von Nebenwirkungen vereinfacht es beträchtlich, Programmbeweise zu führen.

• Haskell ist nicht-strikt. Es werden nur Ausdrücke ausgewertet, die für die Berechnung des Ergebnisses gebraucht werden.

 first x y = x
 quadrat x = x * x

Die Funktion first liefert bei Eingabe zweier Parameter den ersten als Ergebnis zurück. Bei der Eingabe von first x (3+7) ist die Auswertung der Summe (3+7) zur Ergebnisbestimmung nicht notwendig, sollte also unberücksichtigt bleiben.

Die Funktion quadrat berechnet bei Eingabe eines Parameters dessen Quadrat. Bei Eingabe von quadrat(3+5), was im Laufe des Auswertungsprozesses zu (3+5)*(3+5) wird, wäre eine doppelte Berechnung der Summe (3+5) ineffizient, sollte also vermieden werden.

Die Auswertungsstrategie, welche die beiden eben geschilderten Probleme umgeht, wird Bedarfsauswertung (engl. lazy evaluation) genannt und kommt in Haskell meist zum Einsatz.

Die Bedarfsauswertung ist vor allem wegen fehlender Nebeneffekte problemlos möglich, also wegen der strengen Einhaltung des funktionalen Konzepts. Umgekehrt macht die Bedarfsauswertung die funktionale Programmierung angenehmer, denn sie erlaubt es besser, Funktionen zur reinen Berechnung von Ein-/Ausgabefunktionen zu trennen.

Die Bedarfsauswertung erlaubt das Arbeiten mit undefinierten Werten und potentiell unendlich großen Datenmengen. So kann man elegant mit Potenzreihen, Zeitreihen (etwa Audiosignalströmen), Kettenbruchzerlegungen, Entscheidungsbäumen und ähnlichem umgehen. Aber auch bei endlichen, aber großen, oder endlichen und noch nicht vollständig bekannten Daten erlaubt diese Art der Ausführung elegante Programme. So kann man etwa eine Transformation eines XML-Dokumentes als Folge von Transformationen des gesamten XML-Baumes beschreiben. Ausgeführt wird die Gesamttransformation aber von Beginn zum Ende des XML-Dokumentes, auch wenn das Ende noch gar nicht verfügbar ist.

Man beachte allerdings, dass Haskell nach Sprachdefinition lediglich nicht-strikt ist; die Bedarfsauswertung ist nur eine mögliche Implementierung der Nicht-Striktheit (die allerdings von allen gängigen Haskell-Übersetzern angewandt wird). Andere Implementierungen sind möglich (z.B. optimistic evaluation, Ennals & Peyton-Jones, ICFP'03).

Nachher:

Haskell ist eine rein funktionale Programmiersprache ohne imperativen Sprachkonstrukte. Es gibt keine Operationen, die einen Variablenwert verändern. Zustandsabhängige Berechnungen und Ein- und Ausgabeoperationen können durch Verwendung von Monaden rein funktional behandelt werden.

Es gibt keine Unterscheidung zwischen Identität und Gleichwertigkeit von Objekten.

Haskell ist nicht-strikt. Dies wird in konkreten Implementierungen häufig durch Verwendung von Bedarfsauswertung (engl. lazy evaluation) als Auswertungsstrategie realisiert. Andere Implementierungen sind möglich (z.B. optimistic evaluation, Ennals & Peyton-Jones, ICFP'03).

Die Bedarfsauswertung ist vor allem wegen fehlender Nebeneffekte problemlos möglich, also wegen der strengen Einhaltung des funktionalen Konzepts. Umgekehrt macht die Bedarfsauswertung die funktionale Programmierung angenehmer, denn sie erlaubt es besser, Funktionen zur reinen Berechnung von Ein-/Ausgabefunktionen zu trennen.

Meiner Meinung nach sagt die "Nachher"-Version immer noch alles wesentliche, aber eben auf das wesentliche verkürzt. Ich würde aber doch gerne die Meinung einiger anderer Wikipedianer dazu hören. —Tobias Bergemann 16:28, 13. Feb. 2007 (CET)

Nicht-Striktheit vs. Bedarfsauswertung

Im Artikel steht aktuell:

Man beachte allerdings, dass Haskell nach Sprachdefinition lediglich nicht-strikt ist; die Bedarfsauswertung ist nur eine mögliche Implementierung der Nicht-Striktheit

Andererseits unterscheidet Auswertung (Informatik) nur zwei Konzepte: strikte und Bedarfsauswertung (siehe auch non-strict evaluation (engl. Wikipedia)).

Ohne fundiertes Hintergrundwissen erscheint mir die Formulierung unklar: gibt es eine allgemeinere Definition der Nicht-Striktheit (im Gegensatz zu dem, was die zwei verlinkten Lemmata suggerieren) und wenn ja, wie lautet sie?

Sollte eine entspr. Erklärung zu sehr ins Detail gehen, wäre vielleicht auch eine Streichung des entspr. Kommentars angebracht (ggf. noch die Quelle unter "Literatur" aufführen), um den Leser nicht unnötig zu verwirren.

--Hupf 14:35, 29. Mai 2007 (CEST)

scheint ja wirklich verzwickt zu sein. afaik nennt man eine programmiersprache, die bedarfsauswertung nutzt, nicht strikt. demnach heißt eine ps strikt, wenn sie strikte auswertung nutzt. gruß --Murkel ^(anmurkeln) 15:49, 29. Mai 2007 (CEST)

anders gesagt: haskell darf lazy evaluieren, muß aber nicht. -- ∂ 20:50, 6. Nov. 2007 (CET)

Verstehe ich es also richtig, dass die Striktheit schlicht nicht gefordert wird, umgekehrt aber auch nicht die Nicht-Striktheit (=Bedarfsauswertung) - noch anders formuliert: bezüglich der Striktheit werden keine Anforderungen gestellt, Haskell kann sowohl strikt, als auch nicht-strikt ausgewertet werden? In diesem Fall schlage ich eine Formulierung der folgenden Art vor:

Man bedachte allerdings, dass die Sprachdefinition von Haskell keine der beiden Auswertungsstrategien vorschreibt.

Die Sprachdefinition schreibt sehr wohl vor, daß Haskell "non-strict" ist. (Das bedeutet mehr als nur "nicht vollständig strict", es bedeutet "so wenig strict wie möglich"). Die Sprachdefinition schreibt aber nicht vor, wie eine Implementierung das erreicht. Die derzeit vorherrschende Implementierungsmöglichkeit ist die Bedarfsauswertung, es sind aber auch andere Möglichkeiten denkbar (z.B. "optimistic evaluation"). Nicht möglich ist "eager evaluation", denn diese Auswertungsstrategie passt nur zu strikten Sprachen. Man kann also die Begriffspaare "strict" vs. "non-strict" und "lazy" vs. "eager" nicht einfach gleichsetzen. Bei "strict" vs. "non-strict" geht es um die Auswirkung von nicht-terminierenden Teilprogrammen, bei "lazy" vs. "eager" geht es um die Reihenfolge, in der Teilprograme abgearbeitet werden. Diese Fragestellungen interagieren natürlich (wenn ein Teilprogram gar nicht abgearbeitet wird, ist es unerheblich, ob es terminieren würde), sind aber offensichtlicherweise nicht identisch.

Der Artikel stellt die Situation also richtig, wenn auch schwer verständlich dar. Eine bessere Darstellung müßte eigentlich zwischen denotationaler Semantik (welchen mathematischen Funktionen sind mit den Funktionen in einem Haskell-Programm gemeint) und operationaler Semantik (wie wird ein Haskell-Programm vom Computer abgearbeitet) unterscheiden. Haskells Sprachdefinition legt die denotationale Semantik fest, die operationale Semantik bleibt den Implementierungen überlassen.

Für Haskell-Programmierer sind diese feinen Unterschiede allerdings gar nicht relevant, in der Haskell-Community wird das Begriffspaar "strict" vs. "lazy" verwendet, dabei meint "strict" soviel wie "eager (also auch strict)" und "lazy" meint soviel wie "lazy (also auch non-strict)". Daher mein Vorschlag: Im Artikel zunächst das Begriffspaar "strict" vs. "lazy" verwenden, wie es auch in der Haskell-Community verwendet wird, und in einem Absatz am Ende des Artikels dann die Details erklären und auf die Begriffe in der theoretischen Informatik zurückführen. Dann kann man für Programmierer, die sich über Haskell als Programmiersprache informieren wollen, mit einer überschaubaren Anzahl an Begriffen hantieren, und dennoch die formal korrekten Informationen geben.

TillmannRendel 01:47, 17. Nov. 2007 (CET)

Nebenwirkungen

Äääh...

Haskell ist eine rein funktionale Programmiersprache. Funktionen haben keine Nebenwirkungen.

Ich dachte immer, Nebenwirkungen gibt's bei Medikamenten, und globale Variablen in Programmiersprachen induzieren Nebeneffekte. Wie seht ihr das? --Anonymous 20:35, 6. Nov. 2007 (CET)

für mich heißt das (fachsprachlich) "seiteneffekt", was natürlich eigentlich ein falsch übersetzter "side effect", also "nebenwirkung", ist. unser artikel dazu liegt kurioserweise unter Wirkung (Informatik). zu bedenken ist natürlich, daß die community der funktionalen programmierer jede wirkung als unerwünscht betrachten, was ja bei der "nebenwirkung" immer mitschwingt. *g* -- ∂ 20:40, 6. Nov. 2007 (CET)

Bisher in Vorlesungen/deutscher Fachliteratur nur den Begriff Seiteneffekten gehört/gelesen. Sehe die Gefahr der Begriffsbildung bei Verwendung der ungewöhnlichen Übersetzung Nebenwirkung. Deswegen gerade geändert. --Gms 13:54, 18. Mai 2008 (CEST)

Link: http://www.informatik.uni-bonn.de/~ralf/teaching/Hskurs_toc.html

Es scheint dass dieser Link nicht mehr verfügbar ist. -- 84.144.25.234 21:16, 15. Feb. 2010 (CET)

Agda

Thüringer, es gibt einen Dissens, und anstatt etwas fortzuführen, oder anzufangen, was wie ein Edit-War aussieht, hättest spätestens Du eine Diskussion anfangen müssen. Aber ich übernehme mal den Anfang.

Dein letzter Änderungskommentar enthält vor allem die Frage, ob mir aufgefallen sei, dass Agda nicht existiert, und die Frage nach dem Sinn eines solches Eintrags.

Nun, Paul Hudak und Philip Wadler gibt es auch nicht. Ebenso wie Cayenne, Helium und Curry. Soll das irgendein Argument sein?

Was ist falsch an einem Rotlink? Als implizite Aufforderung an Leute, die genügend Zeit und Muße haben, sind die doch gut. Und im konkreten Fall geht es in eine sehr interessante Richtung, nämlich in die von Sprachen mit dependent types, Beweisassistenten, etc.

Zu guter letzt bleibt noch der bereits im Änderungskommentar von mir angegebene Punkt, dass die "beeinflusste"- Eigenschaft auf Agda erheblich viel mehr zutrifft, als auf Scala, und Agda deswegen Erwähnung finden müsste. Falls der Einwand kommt: "[nur oberflächlich und syntaktisch]", siehe http://www.haskell.org/haskellwiki/Wadlers_Law ^^. --Daniel5Ko 00:16, 24. Aug. 2010 (CEST)

Wir reden von einer Infobox. Im Fließtext kannst du gern auf Agda eingehen. Eine Infobox soll einen schnellen Überblick über den Inhalt des Artikels geben. Aber im Artikel wird Agda überhaupt nicht erwähnt! Ich könnte Dir noch einige andere Gründe nennen, aber es ist schon spät. Lies mal WP:Start. --Thüringer ☼ 00:38, 24. Aug. 2010 (CEST)

Mit Deinem nicht-hilfreichen Verweis auf WP:Start (geht's nicht spezifischer?) gehe ich davon aus, dass Du nicht ehrlich diskutieren willst. Es gibt zahlreiche Infoboxen zu Programmiersprachen mit entweder Rotlinks oder trivialen blah-Erwähnungen im Fließtext, die nicht so richtig in diesen hineingehören. Es wäre auch absurd, zu unterstellen, Infoboxen müssten den Artikel zusammenfassen und einen Überblick über diesen bieten. (Weil: Wozu??) Nein, der Sinn ist die Herstellung eines weiteren Kontextes, und ansatzweise eines Überblickes über diesen. --Daniel5Ko 01:54, 24. Aug. 2010 (CEST)

Kommt noch etwas? Ich sehe bisher überhaupt kein funktionierendes Argument gegen die Aufnahme von Agda in die "beeinflusste"- Liste. Dagegen ist es aber offensichtlich, dass ein großer und interessanter Informatik-/Logik-Bereich gänzlich unangetastet und sträflich vernachlässigt ist. Nämlich: Curry-Howard-Isomorphismus, Martin-Löfs Typtheorie, und alles was in diese Richtung geht; dependent types u.a. . Was spricht dagegen, mit einem Rotlink die Wahrscheinlichkeit zu erhöhen, dass jemand neugierig wird, sich irgendwo anders informiert und vielleicht mal einen Artikel schreibt (oder alternativ: sowieso schon Experte ist und durch den Rotlink veranlasst sieht, einen Artikel zu schreiben)?

Mir ist klar, dass das bereits erwähnte Cayenne in die selbe Richtung geht. Mit Agda könnte man aber größere Chancen haben, da das gegenwärtig sehr oft in Freenodes #haskell erwähnt wird. --Daniel5Ko 00:44, 25. Aug. 2010 (CEST)

Zum Einfluss auf andere Programmiersprachen

Haskell diente und dient wegen seiner stark akademischen Herkunft vielen Programmier- und Scriptsprachen als Vorbild für neue Sprachfunktionalität. So haben u.a. Perl, Python, JavaScript, Java, Scala und PHP Ideen der funktionalen Programmierung von Haskell übernommen.

Perl kam 1987 raus, Haskell 1990. War Perl schon immer funktional oder kam erst nach Haskell die funktionale Programmiermöglichkeit hinzu. 88.134.37.238 00:33, 18. Jun. 2013 (CEST)

Ergänzung: Ist das wirklich so, dass explizit Haskell die Entwickler anderer Sprachen zur Übernahme von Ideen der funktionalen Programmierung aus Haskell inspiriert hat? Früher gab es Einführungsveranstaltungen die auf Scheme aufbauten, um auf die Bearbeitung des Buches Structure and Interpretation of Computer Programs vorzubereiten. Zunächst hat John McCarthy inspiriert vom Lambda-Kalkül von Alonzo Church in den 1950er(!)-Jahren den Grundstein für die funktionalen Lisp-Dialekte gelegt. Logo hat Lisp sogar in den US-amerikanischen Schulunterricht gebracht (wie schön, dass der Wert der Turtle als Einstiegshilfe wiederentdeckt worden ist - witziger Weise für Python - im Zuge der Einführung Lingl, Gregor: Python für Kids). M.E. finden sich ganz schöne Referenzen hier (die historischen Informationen finden sich nicht nur in den jeweiligen Vorwörtern der Bücher):

• Harvey, Brian: Scheme vs. Python. Kurze Begründung für die weitere Verwendung von Scheme anstelle von Python für die Lehre, beachte insbesondere 4. (Autoreneintrag aus englischsprachiger Wikipedia hier extern verlinkt)
• ders.: Computer Science Logo Style Volume 1: Symbolic Computing Vorwort
• ders.: Simply Scheme: Introducing Computer Science 2/e Vorwort
• Touretzky, David S.: Common Lisp: A Gentle Introduction to Symbolic Computation (PDF; 1,1 MB)

Danach würde ich annehmen, dass bereits einige Zeit vor der Erstveröffentlichung von Haskell 1990 Lisp seine Einflüsse ausüben konnte. Das so auf Haskell einzudampfen, wie hier vertreten, ... das mag ja stimmen, überrascht mich aber ... weil ja Haskell selbst schlüssiger Weise von Lisp beeinflusst sein müsste. Es ist letztlich egal, weil sich vermutlich alles irgendwie gegenseitig beeinflusst. Nur es klingt gerade deswegen etwas schief, wie hier Haskell in den Vordergrund geschoben zu werden scheint. --93.219.128.40 00:00, 16. Sep. 2017 (CEST)

Hugs

Sollte man nicht Hugs als wichtige Imlementierung aus der Einleitung streichen? Die letzte Version ist von 2006 und Haskell 2010 wird auch nicht unterstützt. GHC dürfte mittlerweile der alleinige Platzhirsch sein. — 79.208.17.24 23:03, 21. Mai 2014 (CEST).

Offenbar keine Einwände. Ich hab Hugs gestrichen. -- 79.208.59.17 09:29, 30. Mai 2014 (CEST).

Hugs ist die bevorzugte Haskell-Implementierung an Hochschulen. Sie muß zumindest erwähnt werden. (nicht signierter Beitrag von 91.66.204.20 (Diskussion) 08:12, 11. Feb. 2015 (CET))

Null Fakultät ist definiert und hat den Wert 1

Die Haskell-Implementierungen (unter Beispiele) der Fakultätsfunktion "rekursiv" (facr) und "endrekursiv" (facrt) können leicht so geändert werden, dass auch 0! korrekt berechnet wird. Hierzu brauchen nur folgende Änderungen gemacht werden:

facr 0 = 1

bzw.

_facrt 0 f = f (nicht signierter Beitrag von 91.6.166.27 (Diskussion) 11:16, 6. Jun. 2014 (CEST))

Richtig. Hab's geändert. -- 79.208.43.237 18:03, 25. Jun. 2014 (CEST).

Beispiel Algebra

Imho ist das Beispiel zur Algebra unverständlich:

"Dieses Beispiel stellt die Nutzung von Typklassen heraus." Was ist der Zusammenhang zw. Algebras und Typklassen? Das sollte irgendwo erklärt werden.

"Ausgenutzt wird das vordefinierte ^, das auf Num-implementierenden Typen arbeitet." Ohne Erklärung wie (^) implementiert ist erkärt das Bsp. gar nix.

Vielleicht wäre ein klassisches Beispiel mit einem Stack und den Operationen push, pull anschaulicher? (nicht signierter Beitrag von 84.226.140.139 (Diskussion) 21:20, 27. Okt. 2014 (CET))

Nutzung von fibs

Für einen unbedarften Anwender ist es unklar, wie man aus der Funktion fibs die zum Beispiel 5. Fibonacci-Zahl erhält. Da wäre ein Beispiel schön.

--Martin schulte (Diskussion) 09:21, 19. Jan. 2021 (CET)