Können Haskell-Funktionen serialisiert werden?

Question

Der beste Weg, es zu tun wäre, um die Darstellung der Funktion zu erhalten (wenn es irgendwie wiederhergestellt werden kann). Binäre Serialisierung wird aus Effizienzgründen bevorzugt.

Ich denke, es gibt einen Weg, es in Clean zu tun, weil es unmöglich wäre, iTask zu implementieren, die darauf angewiesen ist, dass Aufgaben (und damit Funktionen) gespeichert und fortgesetzt werden können, wenn der Server wieder läuft.

Dies muss für verteilte Haskell-Berechnungen wichtig sein.

Ich bin nicht auf der Suche nach Parsing Haskell Code zur Laufzeit wie hier beschrieben: Serialization of functions in Haskell. Ich muss auch serialisieren nicht nur deserialize.

Answer 1

Leider ist das mit dem aktuellen ghc-Laufzeitsystem nicht möglich. Die Serialisierung von Funktionen und anderen beliebigen Daten erfordert einige Low-Level-Laufzeit-Unterstützung, die die ghc-Implementierer nur ungern hinzugefügt haben.

Serialisierungsfunktionen erfordern, dass Sie alles serialisieren können, da beliebige Daten (ausgewertete und nicht bewertete) Teil einer Funktion sein können (z. B. eine Teilanwendung).

Answer 2

Auschecken Cloud Haskell. Es hat ein Konzept, das Closure genannt wird, das verwendet wird, um Code zu senden, der auf entfernten Knoten in einer Art sicheren Weise ausgeführt wird.

Answer 3

Nein. Das CloudHaskell-Projekt macht jedoch deutlich, dass in GHC die explizite Unterstützung der Serialisierung von Schlüssen erforderlich ist. Das nächste, was CloudHaskell explizit sperren muss, ist das distributed-static Paket. Ein weiterer Versuch ist die HdpH closure representation. Beide verwenden jedoch Template Haskell in der Art Thomas describes below.

Die Einschränkung ist ein Mangel an statischer Unterstützung in GHC, für die es derzeit eine unbehandelte GHC ticket gibt. (Irgendwelche Abnehmer?). Es gab a discussion auf der CloudHaskell-Mailingliste darüber, wie statische Unterstützung eigentlich aussehen sollte, aber soweit ich weiß, ist noch nichts fortgeschritten.

Jost Berthold, der die Funktionserialisierung in Eden implementiert hat, ist Jester Design am nächsten gekommen. Siehe sein IFL 2010 Papier "Orthogonal Serialisation for Haskell". Die Unterstützung für die Serialisierung wird in das Eden-Laufzeitsystem eingebunden. (Jetzt als separate Bibliothek verfügbar: packman. Nicht sicher, ob es mit GHC verwendet werden kann oder einen gepatchten GHC wie in der Eden-Gabel benötigt ...) Ähnliches wäre für GHC erforderlich. Dies ist die Unterstützung für die Serialisierung Eden, in der Fassung von GHC gegabelt 7.4:

data Serialized a = Serialized { packetSize :: Int , packetData :: ByteArray# } 
serialize :: a -> IO (Serialized a) 
deserialize :: Serialized a -> IO a 

So: Man kann Funktionen und Datenstrukturen serialisiert. Es gibt eine Binary Instanz für Serialized a, mit der Sie eine lang laufende Berechnung auf Datei prüfen können! (Siehe Abschnitt 4.1).

Die Unterstützung für solch eine einfache Serialisierungs-API in den GHC-Basisbibliotheken wäre sicherlich der Heilige Gral für verteilte Haskell-Programmierung. Es wäre wahrscheinlich die Kombinierbarkeit zwischen den verteilten Haskell Aromen vereinfachen (CloudHaskell, MetaPar, HdpH, Eden und so weiter ...)

Answer 4

Eden wahrscheinlich am nächsten kommt und verdient wahrscheinlich eine separate Antwort: (De-) Serialisierung von unevaluierten Thunks ist möglich, siehe https://github.com/jberthold/packman.

Die Deserialisierung ist jedoch auf das gleiche Programm beschränkt (wobei Programm ein "Kompilierungsergebnis" ist). Da Funktionen als Codezeiger serialisiert werden, können zuvor unbekannte Funktionen nicht deserialisiert werden.

Mögliche Nutzung:

• Speicherung unevaluierten Arbeit für die spätere
• Verteilung von Arbeit (aber kein Austausch neuen Code)

Answer 5

Eine recht einfach und praktisch, aber vielleicht nicht so elegante Lösung wäre sein (vorzugsweise automatisch GHC), kompilieren Sie jede Funktion in ein separates Modul des maschinenunabhängigen Bytecodes, serialisieren Sie diesen Bytecode immer dann, wenn eine Serialisierung dieser Funktion erforderlich ist, und verwenden Sie dynamic-loader oder plugins Pakete, um sie dynamisch zu laden, so dass auch bisher unbekannte Funktionen genutzt werden können.

Da ein Modul alle Abhängigkeiten notiert, können diese auch serialisiert und geladen werden. In der Praxis wäre das Serialisieren von Indexnummern und das Anfügen einer indizierten Liste der Bytecode-Blobs wahrscheinlich am effizientesten.

Ich denke, solange Sie die Module selbst kompilieren, ist dies bereits jetzt möglich.

Wie gesagt, es wäre aber nicht sehr hübsch. Ganz zu schweigen von dem generell großen Sicherheitsrisiko, Code aus unsicheren Quellen zu demerialisieren, um in einer ungesicherten Umgebung zu laufen. :-)
(Kein Problem, wenn es vertrauenswürdig ist, natürlich.)

Ich werde es nicht gleich hier, jetzt aber code. ;-)