Haskell

[CStoll]

ertes schrieb:

CStoll schrieb:

OK, ich formuliere meine Frage neu: Wie würdest du in Haskell den Typ einer Nachfolger-Funktion oder der Negativ-Funktion (f(x)=-x) beschreiben?

Kommt darauf an, was du beweisen willst. Ohne Beweise sind die Typen ziemlich simpel:

negate :: Num a ⇒ a → a
succ :: Num a ⇒ a → a

Das sind auch die Typen, die man in der base-Bibliothek findet. Wenn du hingegen Beweisführung haben willst, gibt es zwei Varianten. Beispiel: Du willst eine Funktion schreiben, die eine nichtnegative Zahl entgegennimmt. Der Typ könnte so aussehen:

sqrt :: PosInt → PosInt

Und was hindert mich nun daran, die succ-Funktion an einer Stelle einzusetzen, an der in meinem Konzept/Spezifikation eigentlich die negate-Funktion erwartet würde?

Eine wirklich sichere Alternative verwendet einen sog. Phantom-Typen:

data NegSign
data NonnegSign
data FlippedSign s

data SInt s where
 SZero :: SInt NonnegSign
 SSucc :: SInt NonnegSign → SInt NonnegSign
 SNegate :: SInt s → SInt (FlippedSign s)

class HasSign a where
 type SignOf a

instance HasSign (SInt NonnegSign) where
 type SignOf (SInt NonnegSign) = NonnegSign

instance HasSign (SInt NegSign) where
 type SignOf (SInt NegSign) = NegSign

instance HasSign (SInt (FlippedSign NonnegSign)) where
 type SignOf (SInt (FlippedSign NonnegSign)) = NegSign

instance HasSign (SInt (FlippedSign (FlippedSign s))) where
 type SignOf (SInt (FlippedSign (FlippedSign s))) = SignOf s

sqrt :: (HasSign a, SignOf a ~ NonnegSign) ⇒ a → a

Wie du siehst, ist das schon sehr viel Tipparbeit, um statisch zu garantieren, dass sqrt nur nichtnegative Zahlen erhält. Abgesehen davon ist die Zahlendarstellung, die ich oben gewählt habe, sehr ineffizient. Daran ließe sich etwas machen, aber dann wäre der Code noch länger. Haskell ist für diese Art von Beweisführung nicht geeignet. Es ist möglich, aber ziemlich aufwendig. Deswegen wird Haskell im Allgemeinen als Programmiersprache und nicht als Beweisassistent bezeichnet. Agda und Coq hingegen sind richtige Beweisassistenten. Mit denen lässt sich so etwas wesentlich leichter ausdrücken, da es in diesen Sprachen keine scharfe Linie mehr zwischen Typ und Wert gibt.

Und jetzt mußt du mir nur noch demonstrieren, wie du eine nackte Zahl (von der du zur Compilierzeit nur weißt, daß sie existiert) in dieses HasSign-Konstrukt verpacken willst.

Und nur zur Sicherheit: Was verstehst du unter dem Typ einer Funktion? Ich verstehe daunter die Angabe, welche Argument- und Ergebnistypen dieser Funktion (bzw. ihr Definitions- und Wertebereich).

So ist es. Allerdings sind Funktionen in Haskell normale Werte und der Typkonstruktor für Funktionen (→) unterscheidet sich nicht von anderen Typkonstruktoren. Damit gibt Haskell jegliche Sonderstellung von Funktionen auf.

Das habe ich auch nicht bestritten.

PS: Das Typsystem ist jetzt klarer - und anscheinend liegen die Typ-Definitionen näher an C#-Generics (man muß explizit angeben, was man von den beteiligten Typen erwartet) als an einem C++ Template (die benötigten Operationen ergeben sich aus der Funktionsdefinition). Das erhöht wirklich die Sicherheit der verwendeten Typen, beschränkt aber imho die Flexibilität.

[volkard]

knivil schrieb:

Noe, wir sind aus dem Land C++ nach Haskell-Heaven gegangen und berichten euch von unseren Erfahrungen.

Auf diesem Neveau wäre alles ok.

knivil schrieb:

Es hat mich auch zu einem besseren C++ Programmierer gemacht.

Auch ok. Lisp hat mich auch zu einem besseren C++-Programmierer gemacht. Ich empfehle sogar jedem, der in C++ weiterkommen will, einen Ausflug in eine Sprache zu machen, die funktionale Programmierung stark fordert. Und ohne Forth hätte ich nie das Programm zum greorianischen Kalender in Brainfuck hingekriegt.

[audacia]

knivil schrieb:

Du kannst gern den entsprechenden Thread verlinken, damit ich selbst nachsehen kann. No review, no study.

Ich glaube kaum, daß du dich an diese 16 Seiten nicht erinnern kannst
http://www.c-plusplus.net/forum/235778

knivil schrieb:

Das ist eine petitio principii. Du /willst/ diese Reaktion, wie deine Wortwahl deutlich zeigt.

Nur kam diese Reaktion vor dem was du zitierst.

Pars pro toto.

[Zeus]

audacia schrieb:

knivil schrieb:

Du kannst gern den entsprechenden Thread verlinken, damit ich selbst nachsehen kann. No review, no study.

Ich glaube kaum, daß du dich an diese 16 Seiten nicht erinnern kannst
http://www.c-plusplus.net/forum/235778

Abgesehen dass der Thread die Halbwertzeit erreicht hat.

[volkard]

audacia schrieb:

Ich glaube kaum, daß du dich an diese 16 Seiten nicht erinnern kannst
http://www.c-plusplus.net/forum/235778

Der erklärt jedenfalls wunderbar, warum knivil jetzt in Haskell so ungemein viel besser programmiert als er es damals in C++ getan hat. Das hatte ich schon aus seinen Postings geschlossen. Hübsch, es nochmal so deutlich lesen zu dürfen.

[ertes]

wertzuddsf schrieb:

Ich hab mal versucht mit Haskell ein einfaches Anfängerprogramm zu schreiben und fand es ziemlich unschön, was ich hinbekommen hab. Kannst du (oder sonst wer) das Programm von unten mal in Haskell schreiben, um zu zeigen, dass es schön geht.

Das hier wäre meine Variante, aber die entspricht nicht exakt deiner. Unterschiede: Man kann das Programm überall mit "q" abbrechen, und das Programm reagiert überall mit Fehlermeldung auf ungültige Eingaben. Und falls dir die Typensignatur von prompt Angst macht: Es geht auch einfacher, aber ich versuche immer, meine Funktionen so allgemein wie möglich zu halten. Die prompt-Funktion lässt sich auch in anderen Anwendungen einsetzen:

{-# LANGUAGE ScopedTypeVariables, TypeFamilies #-}

module Main where

import Control.ContStuff
import Control.Exception as Ex
import System.IO
import System.Random
import Text.Printf

prompt ::
    forall a b m.
    (Abortable m, MonadIO m, Read a, Readable m, Result m ~ StateOf m) =>
    String -> (a -> Maybe b) -> m b
prompt p validate =
    loop

    where
    getNextLine = liftIO (putStr p >> hFlush stdout >> getLine)
    putErrMsg = liftIO (putStrLn "Ungültige Eingabe.")

    loop :: m b
    loop = do
        line <- getNextLine
        when (line == "q") (get >>= abort)
        mResult <- liftM (fmap validate) $ liftIO (Ex.try $ readIO line)
        case mResult of
          Right (Just x)            -> return x
          Left (_ :: SomeException) -> putErrMsg >> loop
          _                         -> putErrMsg >> loop

main :: IO ()
main = do
    let (minNum, maxNum, startBalance) = (0, 3, 100 :: Integer)
        stakePrompt = printf "Sie haben %i Credits.\nEinsatz: "
        guessPrompt = printf "Tipp (von %i bis %i): " minNum maxNum
        between minVal maxVal = Just . max minVal . min maxVal

    putStrLn "Geben Sie \"q\" ein, um das Spiel zu beenden."

    endBalance <- execStateT startBalance . forever $ do
        balance <- get
        when (balance <= 0) (abort 0)

        liftIO (putChar '\n')
        stake <- prompt (stakePrompt balance) (between 1 balance)
        guess <- prompt guessPrompt (between minNum maxNum)
        num <- liftIO $ randomRIO (minNum, maxNum)

        liftIO $ do
            printf "Ihr Einsatz: %i\n" stake
            printf "Ihr Tipp: %i\n" guess
            printf "Geworfen wurde: %i\n" num

        put (balance + (if num == guess then 10*stake else -stake))

    printf "Restliche Credits: %i\n" endBalance

Das contstuff-Paket muss installiert sein. Mit dem Befehl cabal install contstuff kannst du das bewerkstelligen, wenn du die Haskell-Plattform installiert hast. Das Programm ließe sich sicher mit FRP schöner schreiben, aber damit kenne ich mich leider nicht so gut aus. Auch mit der mitgelieferten transformers-Bibliothek lässt sich das Programm auf ähnliche Weise schreiben, aber ich bin contstuff gewohnt.

Th69 schrieb:

Aber besonders beeindruckend fand ich damals die kurze Def. des QuickSort-Algos:

qs [] = []
qs (x:xs) = qs [y|y<-xs; y<=x] ++ [x] ++ qs [y|y<-xs; y>x]

(ich hoffe, ich habe jetzt hier keinen Tippfehler drin

Das Beispiel beeindruckt mich gar nicht. Es sieht zwar an der Oberfläche schön aus, ist aber unglaublich langsam und braucht unglaublich viel RAM. Grund: QuickSort ist für Haskell-Listen überhaupt nicht geeignet. Die Semantik von Listen schreit nach einer MergeSort-Implementierung, und die ist tatsächlich sehr effizient. Mit zwei Zeilen Code kommst du dann allerdings nicht mehr aus. Hier meine MergeSort-Variante:

import Control.Arrow

halves :: [a] -> ([a], [a])
halves [] = ([], [])
halves [x0] = ([x0], [])
halves (x0:x1:xs) = (x0:) *** (x1:) $ halves xs

merge :: Ord a => [a] -> [a] -> [a]
merge [] ys = ys
merge xs [] = xs
merge x@(x0:xs) y@(y0:ys)
    | x0 < y0   = x0 : merge xs y
    | otherwise = y0 : merge x ys

msort :: Ord a => [a] -> [a]
msort [] = []
msort [x] = [x]
msort xs = uncurry merge . (msort *** msort) . halves $ xs

Die halves-Funktion zerlegt eine Liste in zwei Hälften (allerdings nicht durch einen Schnitt in der Mitte, sondern so: [1,2,3,4,5,6] → ([1,3,5], [2,4,6])). Die merge-Funktion vereinigt zwei bereits sortierte Listen. Und die msort-Funktion führt das alles zusammen zum MergeSort-Algorithmus. Wenn man nur auf kurze Codes geil ist, kann man nur Beispiele bringen, die zwar schön aussehen, aber praktisch nichts taugen. Da habe ich aber vor kurzem etwas viel besseres als QuickSort geschrieben:

import Control.Applicative
import Control.Monad
import Data.List

subseqs :: [a] -> [[a]]
subseqs = filterM (const [True, False])

permutations :: [a] -> [[a]]
permutations = foldM (flip $ \x -> zipWith (\l r -> l ++ x:r) <$> inits <*> tails) []

Die subseqs-Funktion liefert alle Teillisten einer Liste. Wenn man eine Liste als Menge betrachtet, dann ist subseqs die Potenzmengenfunktion. Die permutations-Funktion liefert alle Permutationen einer Liste. Diese Funktionen sind im Gegensatz zum QuickSort-Beispiel tatsächlich effizient, aber sie sind wohl eher Beispiele davon, wie obskur man mit Monaden programmieren kann. Selbst eingefleischte Haskeller brauchen eine Weile, um diese Beispiele zu verstehen.

CStoll schrieb:

Und was hindert mich nun daran, die succ-Funktion an einer Stelle einzusetzen, an der in meinem Konzept/Spezifikation eigentlich die negate-Funktion erwartet würde?

Im ersten Beispiel gar nichts. Die Garantie ist da nur, dass eine Funktion, die eine Zahl erwartet, auch eine Zahl bekommt, also nicht besonders beeindruckend. Im zweiten Beispiel kannst du aus einer negativen Zahl kein PosInt konstruieren. Allerdings habe ich keine Implementierung zu PosInt angegeben. Auch hier gibt es wieder zwei Möglichkeiten: Entweder du schreibst PosInt als Verpackung von Integer und dazu eine intToPosInt-Funktion, die zur Laufzeit prüft, oder du implementierst PosInt auf eine Art, die negative Zahlen konzeptionell ausschließt, etwa so:

data PosInt = PosChunk Word32 | PosEnd

Falls dir 32 Bits ausreichen, kannst auch auf das Chunking verzichten und dir eine Menge Implementierungsaufwand sparen:

newtype PosInt = PosInt Word32

Der Nachteil, dass man zwei Negierungsfunktionen braucht, bleibt aber bestehen. Besonders schön ist diese Variante also in keinem Fall.

Und jetzt mußt du mir nur noch demonstrieren, wie du eine nackte Zahl (von der du zur Compilierzeit nur weißt, daß sie existiert) in dieses HasSign-Konstrukt verpacken willst.

Eine negative Zahl mit dem Typ SInt NonnegSign ist konzeptionell ausgeschlossen. Diese Prüfung musst du also zur Laufzeit durchführen, bevor die Zahl in das SInt-Konzept eindringt, etwa durch folgende Funktion:

posSInt :: Integer -> Maybe (SInt NonnegSign)

Ist die Zahl negativ, liefert die Funktion Nothing.

Das habe ich auch nicht bestritten.

PS: Das Typsystem ist jetzt klarer - und anscheinend liegen die Typ-Definitionen näher an C#-Generics (man muß explizit angeben, was man von den beteiligten Typen erwartet) als an einem C++ Template (die benötigten Operationen ergeben sich aus der Funktionsdefinition). Das erhöht wirklich die Sicherheit der verwendeten Typen, beschränkt aber imho die Flexibilität.

Im Gegenteil. Das Typensystem von Haskell erlaubt higher order polymorphism, was in C# (und allen anderen .NET-Sprachen) etwa die Übersetzung generic generics hätte und nicht möglich ist. C++ erlaubt eine schwache Form davon und nennt sie template templates. Dieses Konzept ist der Grundstein der in Haskell so beliebten Monaden, denn ohne das wären sie völlig nutzlos.

Dadurch hast du die Flexibilität von C++ kombiniert mit der Sicherheit von C#. In F# hat Microsoft ein OOP-basiertes Workaround gefunden, um doch noch Monaden in das Sprachkonzept mit aufnehmen zu können, aber ohne die Vorteile von Ableitung und Generalisierung, die du in Haskell hast. Du müsstest Haskells mapM-Funktion etwa für jede Monade separat implementieren, und der Code wäre jedes mal der gleiche. In Haskell implementierst du sie einmal für alle Monaden. Das Workaround schließt auch alle erweiterten Konzepte aus, die Monaden als Basis haben, etwa monad transformers. Kurz: In C# (LINQ) und F# (computation expressions) sind Monaden nur ein starres Design-Pattern für ein paar Sonderfälle. Sie kommen nicht annähernd an echte Monaden heran.

[ertes]

ertes schrieb:

data PosInt = PosChunk Word32 | PosEnd

Sorry, mein Fehler. Es müsste lauten:

data PosInt = PosChunk Word32 PosInt | PosEnd

[CStoll]

ertes schrieb:

Im ersten Beispiel gar nichts. Die Garantie ist da nur, dass eine Funktion, die eine Zahl erwartet, auch eine Zahl bekommt, also nicht besonders beeindruckend. Im zweiten Beispiel kannst du aus einer negativen Zahl kein PosInt konstruieren. Allerdings habe ich keine Implementierung zu PosInt angegeben. Auch hier gibt es wieder zwei Möglichkeiten: Entweder du schreibst PosInt als Verpackung von Integer und dazu eine intToPosInt-Funktion, die zur Laufzeit prüft, oder du implementierst PosInt auf eine Art, die negative Zahlen konzeptionell ausschließt, etwa so:

data PosInt = PosChunk Word32 | PosEnd

Falls dir 32 Bits ausreichen, kannst auch auf das Chunking verzichten und dir eine Menge Implementierungsaufwand sparen:

newtype PosInt = PosInt Word32

Der Nachteil, dass man zwei Negierungsfunktionen braucht, bleibt aber bestehen. Besonders schön ist diese Variante also in keinem Fall.

Und jetzt mußt du mir nur noch demonstrieren, wie du eine nackte Zahl (von der du zur Compilierzeit nur weißt, daß sie existiert) in dieses HasSign-Konstrukt verpacken willst.

Eine negative Zahl mit dem Typ SInt NonnegSign ist konzeptionell ausgeschlossen. Diese Prüfung musst du also zur Laufzeit durchführen, bevor die Zahl in das SInt-Konzept eindringt, etwa durch folgende Funktion:

posSInt :: Integer -> Maybe (SInt NonnegSign)

Also lässt sich offenbar doch nicht alles durch den Compiler sicherstellen.

Und außerdem habe ich bei Zahlen auch vor, weiter damit zu rechnen. Also welchen Typ würdest du für die Differenz zweier (positiver) Zahlen angeben.

Und da hier schon einiges über Sortieralgorithmen genannt wurde: Kann der Compiler dir beweisen, daß eine Funktion (Ordered a) => [a] -> [a] eine sortierte Kopie des übergebenen Parameters zurückgibt?

Im Gegenteil. Das Typensystem von Haskell erlaubt higher order polymorphism, was in C# (und allen anderen .NET-Sprachen) etwa die Übersetzung generic generics hätte und nicht möglich ist. C++ erlaubt eine schwache Form davon und nennt sie template templates. Dieses Konzept ist der Grundstein der in Haskell so beliebten Monaden, denn ohne das wären sie völlig nutzlos.

Ich sagte "näher". C++ Templates verwenden die Operationen, die sie brauchen, und der Compiler beschwert sich wenn die konkreten Template-Parameter sie nicht unterstützen. Bei Haskell und C# muß man explizit angeben, welche Operationen du erwartest und kannst nur diese verwenden.

[ertes]

@CStoll: Was zur Laufzeit reinkommt, muss natürlich auch zur Laufzeit geprüft werden. Du kannst aber statisch sicherstellen, dass diese Prüfung korrekt (also der Spezifikation konform) abläuft. Das Weiterrechnen ist in diesem Framework möglich, erfordert aber auch wieder sehr viel Code, weil du auch dafür wieder Klassen und Instanzen brauchst. Wie gesagt: Haskell ist dafür nicht wirklich geeignet. Es ist möglich, aber sehr aufwendig. Da solltest du schon auf einen richtigen Beweisassistenten zugreifen.

Ich sagte "näher". C++ Templates verwenden die Operationen, die sie brauchen, und der Compiler beschwert sich wenn die konkreten Template-Parameter sie nicht unterstützen. Bei Haskell und C# muß man explizit angeben, welche Operationen du erwartest und kannst nur diese verwenden.

Das macht doch keinen Flexibilitätsunterschied. Du musst halt in Haskell mehr spezifizieren und hast am Ende wahrscheinlich trotzdem weniger Code, weil C++ im Vergleich ziemlich viel Rauschen enthält.

[CStoll]

ertes schrieb:

@CStoll: Was zur Laufzeit reinkommt, muss natürlich auch zur Laufzeit geprüft werden. Du kannst aber statisch sicherstellen, dass diese Prüfung korrekt (also der Spezifikation konform) abläuft. Das Weiterrechnen ist in diesem Framework möglich, erfordert aber auch wieder sehr viel Code, weil du auch dafür wieder Klassen und Instanzen brauchst. Wie gesagt: Haskell ist dafür nicht wirklich geeignet. Es ist möglich, aber sehr aufwendig. Da solltest du schon auf einen richtigen Beweisassistenten zugreifen.

Und im Endeffekt muß ich diese Prüfung doch bei jeder Funktion durchführen, die nicht auf dem gesamten Wertebereich definiert ist - Wurzel, Logarithmus, Arcus-Funktionen etc. (abgesehen davon hängen die Beschränkungen auch davon ab, welchen Wertebereich du verwendest)

Ich sagte "näher". C++ Templates verwenden die Operationen, die sie brauchen, und der Compiler beschwert sich wenn die konkreten Template-Parameter sie nicht unterstützen. Bei Haskell und C# muß man explizit angeben, welche Operationen du erwartest und kannst nur diese verwenden.

Das macht doch keinen Flexibilitätsunterschied. Du musst halt in Haskell mehr spezifizieren und hast am Ende wahrscheinlich trotzdem weniger Code, weil C++ im Vergleich ziemlich viel Rauschen enthält.

Was meinst du mit "Rauschen"? Die Tatsache, daß man in C++ lesbare Schlüsselwörter wie template oder return verwendet? Das erhöht aber auch die Lesbarkeit des Codes.

[volkard]

ertes schrieb:

weil C++ im Vergleich ziemlich viel Rauschen enthält.

Rauschen ist nicht das richtige Wort. Rauschen klingt nach unerwünschten Funkstörungen. In C++ würde man mehr Zeichen tippen müssen, aber die rauscht man nicht in die Tastatur rein. Redundaz ist nicht Rauschen.

[Zeus]

volkard schrieb:

ertes schrieb:

weil C++ im Vergleich ziemlich viel Rauschen enthält.

Rauschen ist nicht das richtige Wort. Rauschen klingt nach unerwünschten Funkstörungen. In C++ würde man mehr Zeichen tippen müssen, aber die rauscht man nicht in die Tastatur rein. Redundaz ist nicht Rauschen.

Ihm rauscht es aber von seine funktionale Sicht der Dinge. Seine Herleitung sind subjektiv, deswegen schmunzeln ich lieber darüber.

[volkard]

Zeus schrieb:

Ihm rauscht es aber von seine funktionale Sicht der Dinge. Seine Herleitung sind subjektiv, deswegen schmunzeln ich lieber darüber.

Ja, soo gesehen...
Ich finde, daß nur "<>+-.,[]" Information tragen, Buchstaben sind Rauschen. Wobei ich betone, daß ich Buchstaben gerne für Kommentare einsetze und sie für sinnvoll halte.

[Irgendwer]

Die Tatsache, daß man in C++ lesbare Schlüsselwörter wie template oder return verwendet? Das erhöht aber auch die Lesbarkeit des Codes.

Ja, aber Haskell geht nunmal einen anderen Weg.

Man lässt z.B. einfach beim Funktionsaufruf die Klammern weg, da Funktionsaufrufe das sind, was in einer funktionalen Sprache am häufigsten vorkommt. Genauso muss man im Funktionskopf eines Templates die Template-Parameter nicht mit dem Schlüsselwort "template" einführen, sondern über die Regel, dass nur Typen mit einem Großbuchstaben beginnen, ist klar, dass ein kleiner Buchstabe in der Funktionsdefinition eine Typvariable ist:

Funktion von Float nach Int:
f :: Float -> Int

Funktion von irgendeinem Typ nach Int:
f :: a -> Int

Solche Sachen finden sich ständig in Haskell. Z.B. ist auch die Lambda-Syntax wunderbar einfach:
f = \x -> ...

Oder auch die Möglichkeit lokal begrenzte Funktionen/Werte mit "where" einzuführen.
Alles Dinge, die die Lesbarkeit stark erhöhen und Haskell für mich zu einer sehr schönen und eleganten Sprache machen.

[ertes]

CStoll schrieb:

Und im Endeffekt muß ich diese Prüfung doch bei jeder Funktion durchführen, die nicht auf dem gesamten Wertebereich definiert ist - Wurzel, Logarithmus, Arcus-Funktionen etc. (abgesehen davon hängen die Beschränkungen auch davon ab, welchen Wertebereich du verwendest)

Falsch. Diese Prüfung führst du an der Stelle durch, in der Zahlen das Konstrukt betreten. Zum Zeitpunkt, an dem die genannten Funktionen aufgerufen werden, hat diese Prüfung schon lange stattgefunden. Tatsächlich kannst du keine sqrt-Funktion schreiben, die nicht mit NonnegSign definiert ist.

Was meinst du mit "Rauschen"? Die Tatsache, daß man in C++ lesbare Schlüsselwörter wie template oder return verwendet? Das erhöht aber auch die Lesbarkeit des Codes.

Ich finde Haskell nicht schwerer zu lesen trotz weniger Rauschen. "Rauschen" ist übrigens eine direkte Übersetzung von "line noise", da mir kein besserer Begriff eingefallen ist. Es ist nicht zwangsläufig etwas Negatives, aber es ist halt mehr zu tippen und mehr zu lesen für weniger Information. Beispiel:

template <template <typename> class F, typename A, typename B> F<B> someFunc(B (*f)(A), F<A> c) {
    …
}

Haskell:

someFunc :: Functor f => (a -> b) -> f a -> f b
someFunc f c = …

C# etwa verbessert diese Syntax dramatisch, aber da kann man die o.g. Funktion erst gar nicht ausdrücken, da es keine generic generics gibt. Man muss sich da auf OOP und dynamisches Casting verlassen, was sehr unschön ist, selbst wieder sehr viel Rauschen reinbringt und außerdem fehleranfälliger ist.

Irgendwer schrieb:

Man lässt z.B. einfach beim Funktionsaufruf die Klammern weg, da Funktionsaufrufe das sind, was in einer funktionalen Sprache am häufigsten vorkommt. Genauso muss man im Funktionskopf eines Templates die Template-Parameter nicht mit dem Schlüsselwort "template" einführen, sondern über die Regel, dass nur Typen mit einem Großbuchstaben beginnen, ist klar, dass ein kleiner Buchstabe in der Funktionsdefinition eine Typvariable ist: […]

Es gibt auch Alternativen zu C++, deren Syntax etwas besser ist, aber trotzdem fehlt mir in diesen Sprachen einfach die prägnante Syntax und die Typinferenz. In C++ musst du oft a<B> schreiben, obwohl aus dem Kontext völlig klar ist, was B ist. Es ist nicht die Redundanz, die mich stört, sondern die unnötige Redundanz. Das ist das, was ich als Rauschen sehe.

Außerdem bevorzuge ich Kombinatoren den expliziten Kontrollstrukturen wie Schleifen. Zu letzteren zähle ich übrigens auch explizite Rekursion. Die braucht man in Haskell selten. Und schließlich fehlt mir in C++ die Möglichkeit, Koroutinen zu schreiben.

[volkard]

ertes schrieb:

Es ist nicht die Redundanz, die mich stört, sondern die unnötige Redundanz. Das ist das, was ich als Rauschen sehe.

Bitte nenne sie unnötige Redundanz. Rauschen ist ein Schmähwort. Auch bei den Amis.

[CStoll]

ertes schrieb:

CStoll schrieb:

Und im Endeffekt muß ich diese Prüfung doch bei jeder Funktion durchführen, die nicht auf dem gesamten Wertebereich definiert ist - Wurzel, Logarithmus, Arcus-Funktionen etc. (abgesehen davon hängen die Beschränkungen auch davon ab, welchen Wertebereich du verwendest)

Falsch. Diese Prüfung führst du an der Stelle durch, in der Zahlen das Konstrukt betreten. Zum Zeitpunkt, an dem die genannten Funktionen aufgerufen werden, hat diese Prüfung schon lange stattgefunden. Tatsächlich kannst du keine sqrt-Funktion schreiben, die nicht mit NonnegSign definiert ist.

Hast du schonmal daran gedacht, daß nicht jede Funktion garantieren kann, daß ihr Rückgabewert positiv ist? Einfachstes Beispiel ist die Subtraktion, also wie würdest du die schreiben, um f(x,y)=sqrt(x-y) ohne Laufzeitprüfungen berechnen zu können?

In C++ musst du oft a<B> schreiben, obwohl aus dem Kontext völlig klar ist, was B ist.

Der Compiler hat eventuell ein anderes Verständnis von Kontext als du Und außerdem habe ich gehört, daß es im neuesten C++ Standard das Schlüsselwort auto geben soll, daß diese redundanten Typ-Nennungen reduziert.

Es ist nicht die Redundanz, die mich stört, sondern die unnötige Redundanz. Das ist das, was ich als Rauschen sehe.

Und wo ziehst du die Grenze zwischen nötiger und unnötiger Redundanz?

PS: Meine Frage nach der Validierung von Sortieralgorithmen durch den Compiler hast du auch nicht beantwortet.

[knivil]

vor kurzem etwas viel besseres als QuickSort geschrieben .. Potenzmengenfunktion .. permutations

a) wenn in der Typsignatur Nur mit Listen gearbeitet wird. warum nutzt du dann foldM, filterM etc. b) diese Funktionen sind bereits in List enthalten, sie brauchen nicht selbst implementiert werden. Und das Verstaendnisproblem ruehert daher, dass sie eben nicht kanonisch implementiert sind.

[ertes]

CStoll schrieb:

Hast du schonmal daran gedacht, daß nicht jede Funktion garantieren kann, daß ihr Rückgabewert positiv ist? Einfachstes Beispiel ist die Subtraktion, also wie würdest du die schreiben, um f(x,y)=sqrt(x-y) ohne Laufzeitprüfungen berechnen zu können?

Deine Funktion f kompiliert einwandfrei. Sie kann nur nicht mit jedem Argumentpaar ausgeführt werden. Wenn der Compiler beweisen kann, dass x - y niemals negativ wird, also dass x ≥ y ist, dann ist auch dein Funktionsaufruf gültig. Falls du das nicht statisch sicherstellen kannst, musst du das eben zur Laufzeit machen. Das lässt sich machen, aber es wird mir langsam zu anstrengend, für alles Codebeispiele zu liefern.

Ich habe mehrfach gesagt, dass Haskell für diese Art von statischen Garantien nicht geeignet ist. Es wird Zeit, dass du das berücksichtigst. Wenn du solche Garantien willst, musst du Agda oder Coq nehmen.

Der Compiler hat eventuell ein anderes Verständnis von Kontext als du Und außerdem habe ich gehört, daß es im neuesten C++ Standard das Schlüsselwort auto geben soll, daß diese redundanten Typ-Nennungen reduziert.

Das ist richtig. Typinferenz in Haskell ist global, und in Standard-H98 musst du normalerweise keine Typensignaturen schreiben. Aber ich sehe es als guten Programmierstil an, sie trotzdem anzugeben, da die Typen deine Spezifikation sind.

Und wo ziehst du die Grenze zwischen nötiger und unnötiger Redundanz?

Sobald sie sich anfühlt wie Boilerplate ist sie für mich unnötig.

PS: Meine Frage nach der Validierung von Sortieralgorithmen durch den Compiler hast du auch nicht beantwortet.

Habe ich überlesen, sorry. Sortiertheit ist eigentlich relativ einfach statisch zu garantieren. Das habe ich schon mal gemacht via GADTs.

knivil schrieb:

a) wenn in der Typsignatur Nur mit Listen gearbeitet wird. warum nutzt du dann foldM, filterM etc. b) diese Funktionen sind bereits in List enthalten, sie brauchen nicht selbst implementiert werden. Und das Verstaendnisproblem ruehert daher, dass sie eben nicht kanonisch implementiert sind.

Du verwechselst da was. Die Funktionen filterM und foldM sind Verallgemeinerungen von filter und foldl. Das erkennt man, wenn man die Typensignaturen vergleicht:

filter :: (a → Bool) → [a] → [a]
filterM :: Monad m ⇒ (a → m Bool) → [a] → m [a]

foldl :: (b → a → b) → b → [a] → b
foldM :: Monad m ⇒ (b → a → m b) → b → [a] → m b

Die Funktionen sind äquivalent in der Identitätsmonade (Id m ist isomorph zu m), können sich in anderen Monaden aber drastisch voneinander unterscheiden. Meine Code-Beispiele bewegen sich in der Listenmonade, also ist m = []. Definiert sind die Funktionen in Control.Monad.

[!rr!rr_.]

die Haskell Version des Glückspiel-Programms ist länger und für Nicht-Haskellaner schwerer zu verstehen als es die C++ Version für Nicht-C++er ist. Außerdem sehe ich in der haskell-Version 4-mal "do" ... nicht gerade das typischste Element funktionaler Programmierung.

Gut, der Glücksspiel-Algo ist allerdings auch ein "Heimspiel" für klassische imperative Programmierung. Eine ganz andere Problemstellung, die beispielsweise zustandsfreie rekursive Datenstrukturen verlangte, wäre da eine bessere "Reklame" für Funk Prog.

Trotzdem ist das Beispiel nicht geeignet, meine Skepsis über die Vorteile von Funk Prog bei "real world"-Problemstellungen zu verringern.