Haskell ohne Typen

Kann das Typsystem in Haskell deaktiviert oder umgangen werden? Es gibt Situationen, in denen es praktisch ist, wenn alles wie in Forth und BCPL oder wie in Mathematica monotypisiert ist. Ich denke an die Art, alles als den gleichen Typ zu deklarieren oder die Typprüfung insgesamt zu deaktivieren.Haskell ohne Typen

Bearbeiten: In Übereinstimmung mit SO-Prinzipien ist dies eine enge technische Frage, nicht eine Anfrage für die Diskussion der relativen Vorzüge verschiedener Programmieransätze. Um die Frage neu zu formulieren: "Kann Haskell so verwendet werden, dass die Vermeidung von Typkonflikten vollständig in der Verantwortung des Programmierers liegt?"

Quelle

2012-05-25 user287424

[nein] (http://dmwit.com/bacteria/grumpy.jpg) –

Bequem, vielleicht. Aber beachte, dass die von dir verwendete Lösung nicht kulturell idiomatisch sein wird, was immer stark typisiert ist. Ich schlage vor, dass Sie Ihre "Unannehmlichkeiten" hinter sich lassen und es auf die kulturell normative Art lernen - wenn Sie erst einmal etwas Zeit damit verbracht haben, wird alles zusammenfallen und Sie werden sich fragen, warum Sie dachten, Sie müssten den Typ-Checker deaktivieren. – luqui

+1 für die Verwendung von "kulturell normativ" bei der Beantwortung einer Programmierfrage. –

Sehen Sie sich auch Data.Dynamic an, mit dem Sie dynamisch typisierte Werte in Teilen Ihres Codes eingeben können, ohne die Typprüfung zu deaktivieren.

Quelle

2012-05-25 02:41:30

Natürlich wird man immer noch Fehler bekommen, wenn man versucht, Daten zu manipulieren, deren Wert in irgendeinem Zusammenhang keinen Sinn ergibt. z.B. versuchen, eine Zeichenfolge zu einem int hinzuzufügen. Ich denke nicht, dass dieses Modul das ändert. – Wes

Ich werde diesen einen Versuch geben. – user287424

GHC 7.6 (noch nicht erschienen) hat eine ähnliche Funktion bietet, -fdefer-type-errors:

http://hackage.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime

Es werden alle Typfehler erst zur Laufzeit verschieben. Es ist nicht wirklich untypisch, aber es erlaubt fast so viel Freiheit.

Quelle

2012-05-25 02:29:52 Pubby

Wie Pubby bemerkt, ist dies * nicht * das gleiche wie dynamische Typisierung. Konkret ist der Unterschied: Nehmen Sie '-Fehler-Typ-Fehler' an und betrachten Sie die Funktion' addOne :: a -> a' definiert durch 'addOne x = x + 1'.Dies hat eindeutig einen Typfehler, und das Aufrufen von 'addOne "x" 'wird fehlerhafterweise ausgegeben. Jedoch wird 'addOne (1 :: Int)' (wie ich es verstehe) * auch * error: obwohl der Code in diesem Fall zufällig funktionieren würde, * ist es immer noch falsch *, und Sie erhalten den Fehler, den Sie * hätte * zur Kompilierzeit bekommen. –

Es bietet keine Freiheit vom Typsystem. Es ist nicht beabsichtigt, das Typsystem auszuschalten, sondern es nur zu verzögern, wenn der fragliche Fehler zur Kompilierzeit nicht relevant für "main" ist. – rotskoff

Selbst mit fdefer-type-errors würde man das Typsystem nicht umgehen. Es erlaubt auch keine Typunabhängigkeit. Der Punkt des Flags besteht darin, Code mit Typfehlern zu kompilieren, solange die Fehler nicht von der Main-Funktion aufgerufen werden. Insbesondere wird jeder Code mit einem Typfehler, der tatsächlich von einem Haskell-Interpreter aufgerufen wurde, weiterhin fehlschlagen.

Während die Aussicht auf untypisierte Funktionen in Haskell verlockend sein könnte, ist es erwähnenswert, dass das Typsystem wirklich im Zentrum der Sprache steht. Der Code beweist seine eigene Funktionalität in der Kompilierung, und die Starrheit des Typsystems verhindert eine große Anzahl von Fehlern.

Vielleicht, wenn Sie ein konkretes Beispiel für das Problem geben, das Sie haben, könnte die Gemeinschaft es ansprechen. Die Interkonvertierung zwischen den Zahlentypen ist etwas, worum ich vorher gefragt habe, und es gibt eine Reihe guter Tricks.

Quelle

2012-05-25 05:39:20 rotskoff

Für die interessierten, zwei wichtige Anwendungsbereiche, in denen dies relevant ist, sind explorative Programmierung (z. B. KI-Forschung) und symbolische Mathematik. Siehe Diskussion unter Lispern, die Haskell ausprobiert haben, aber wegen des Typsystems zurückgeschalten haben. Lesen Sie in der Computeralgebra, warum das stark typisierte Axiom-System bei Mathematikern nicht akzeptiert wurde. – user287424

Hinweis: Der obige Wortlaut "Der Punkt des Flags ist es, Code mit Typfehlern zu kompilieren, solange die Fehler nicht in Main angezeigt werden. Insbesondere wird jeder Code mit einem Typfehler, wenn zur Laufzeit aufgerufen wird, noch Scheitern." ist vage und potenziell irreführend. D.h., was bedeuten "in Main" und "zur Laufzeit genannt"? Siehe [das Papier] (http://dreixel.net/research/pdf/epdtecp_draft.pdf) für eine bessere Intuition. Z.B. 'fst (True, 'a' && False)' ergibt 'True', nachdem es in' fst übersetzt wurde (True, error "Type error: Char konnte nicht mit Bool übereinstimmen"). – ntc2

Auf der anderen Seite, siehe 'addOne' [unten] (http://StackOverflow.com/questions/10747703/haskell-without-types#comment13967400_10747745) für ein Beispiel, wo Sie vielleicht keinen Fehler erwarten, aber einen bekommen. Eine bessere Zusammenfassung könnte also sein: Typfehler werden so weit wie möglich (heuristisch) lokalisiert (in die Blätter des Ausdrucksbaums geschoben) und dann durch Aufrufe von "Fehler" ersetzt. Die Lazy-Bewertung von Haskell bedeutet, dass diese Fehleraufrufe nicht ausgelöst werden, wenn der (Kopf-) Wert ihrer Ausdrücke zur Laufzeit nicht benötigt wird. – ntc2

Haskell ohne Typen

Antwort

Verwandte Themen