Diskussion:Haskell (Programmiersprache)

message: 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)
replies: text: 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)

text: 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)
replies: text: Siehe beispielsweise http://www.haskell.org/haskellwiki/Haskell_in_industry --Plaicy 02:37, 4. Mär. 2007 (CET)
thread_title:  Verwendung 

message: 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)
thread_title:  Effizienter Quicksort 

message: 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)
thread_title:  Francis Haskell 

message: "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)
replies: text: 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)
thread_title:  Python? 

message: 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)
thread_title:  Quicksort? Oder eher Mergesort? 

message: [ 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)
replies: text: 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)
replies: text: Jetzt hat jemand den ersten Vorschlag übernommen.  Dann hat sich das wohl erledigt.--Plaicy 16:36, 4. Mär 2006 (CET)
thread_title:  List notation 

message: 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)
replies: text: 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)
thread_title:  Praxiseinsatz? 

message: 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)
thread_title:  Beispiele 

message: 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)
thread_title:  Redundanzen mit anderen Artikeln 

message: 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)
replies: text: 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)
replies: text:  anders gesagt: haskell darf lazy evaluieren, muß aber nicht. -- ∂ 20:50, 6. Nov. 2007 (CET)
replies: text:  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)
thread_title:  Nicht-Striktheit vs. Bedarfsauswertung 

message: Äää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)
replies: text: 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)

text: 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)
thread_title:  Nebenwirkungen 

message: Es scheint dass dieser Link nicht mehr verfügbar ist. -- 84.144.25.234 21:16, 15. Feb. 2010 (CET)
thread_title:  Link: http://www.informatik.uni-bonn.de/~ralf/teaching/Hskurs_toc.html 

message: 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)
replies: text: Offenbar keine Einwände. Ich hab Hugs gestrichen. -- 79.208.59.17 09:29, 30. Mai 2014 (CEST)
replies: text:  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)
thread_title:  Hugs 

message: 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)
replies: text:  Richtig. Hab's geändert. -- 79.208.43.237 18:03, 25. Jun. 2014 (CEST)
thread_title:  Null Fakultät ist definiert und hat den Wert 1 

message: 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)
thread_title:  Beispiel Algebra 

message: 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)
thread_title:  Nutzung von fibs