Le funzioni di Haskell possono essere serializzate?

Question

Il modo migliore per farlo sarebbe ottenere la rappresentazione della funzione (se può essere recuperata in qualche modo). La serializzazione binaria è preferita per motivi di efficienza.

Penso che ci sia un modo per farlo in Pulito, perché sarebbe impossibile implementare iTask, che si basa su tali attività (e quindi sulle funzioni) può essere salvato e continuato quando il server è di nuovo in esecuzione.

Questo deve essere importante per i calcoli haskell distribuiti.

Non sto cercando di analizzare il codice haskell in fase di esecuzione come descritto qui: Serialization of functions in Haskell. Ho anche bisogno di serializzare non solo deserializzare.

Answer 1

Sfortunatamente, non è possibile con l'attuale sistema di runtime ghc. La serializzazione di funzioni e altri dati arbitrari richiede un supporto di runtime di basso livello che gli implementatori ghc sono stati riluttanti ad aggiungere.

Le funzioni di serializzazione richiedono che sia possibile serializzare qualsiasi cosa, poiché i dati arbitrari (valutati e non valutati) possono far parte di una funzione (ad es. Un'applicazione parziale).

Answer 2

Check out Cloud Haskell. Ha un concetto chiamato Closure che viene utilizzato per inviare codice da eseguire su nodi remoti in un modo sicuro.

Answer 3

No. Tuttavia, il progetto CloudHaskell sta portando a casa la necessità di un supporto esplicito per la serializzazione della chiusura in GHC. La cosa più vicina a CloudHaskell per le chiusure esplicite è il pacchetto distributed-static. Un altro tentativo è il HdpH closure representation. Tuttavia, entrambi utilizzano Template Haskell nel modo Thomas describes below.

La limitazione è la mancanza di supporto statico in GHC, per il quale esiste un GHC ticket non gestito. (Qualsiasi acquirente?). Nella mailing list di CloudHaskell c'è stato il a discussion su quale dovrebbe essere il supporto statico, ma per quanto ne so non è ancora progredito.

Il più vicino a chiunque sia arrivato a una progettazione e implementazione è Jost Berthold, che ha implementato la serializzazione delle funzioni in Eden. Vedi il suo documento IFL 2010 "Orthogonal Serialisation for Haskell". Il supporto per la serializzazione è integrato nel sistema di runtime Eden. (Ora disponibile come libreria separata: packman. Non sono sicuro se può essere usato con GHC o ha bisogno di un GHC rattoppato come nella forcella Eden ...) Qualcosa di simile sarebbe necessario per GHC. Questo è il supporto serializzazione Eden, nella versione biforcuta dalla GHC 7.4:

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

Quindi: si può serializzare funzioni e strutture di dati. C'è un'istanza Binary per Serialized a, che ti consente di controllare un calcolo a lungo eseguito su file! (Vedere la sezione 4.1).

Il supporto per una semplice API di serializzazione nelle librerie di base GHC sarebbe sicuramente il Santo Graal per la programmazione Haskell distribuita. Sarebbe probabilmente semplificare la componibilità tra i sapori Haskell distribuiti (CloudHaskell, MetaPar, HdpH, Eden e così via ...)

Answer 4

Eden probabilmente si avvicina di più e probabilmente merita una risposta separata: (de-) serializzazione di thunk non valutate è possibile, vedi https://github.com/jberthold/packman.

La deserializzazione è tuttavia limitata allo stesso programma (in cui il programma è un "risultato di compilazione"). Poiché le funzioni sono serializzate come puntatori di codice, le funzioni precedentemente sconosciute non possono essere deserializzate.

utilizzo possibile:

• memorizzazione lavoro non valutata per dopo
• distribuire il lavoro (ma nessuna condivisione di nuovo codice)

Answer 5

Una soluzione abbastanza semplice e pratico, ma forse non così elegante sarebbe preferibilmente (preferibilmente avere GHC automaticamente) compilare ciascuna funzione in un modulo separato di bytecode indipendente dalla macchina, serializzare quel codice byte ogni volta che viene richiesta la serializzazione di tale funzione e utilizzare dynamic-loader o plugins pacchetti, per caricarli dinamicamente, quindi è possibile utilizzare anche funzioni precedentemente sconosciute.

Poiché un modulo rileva tutte le sue dipendenze, quelle potrebbero quindi essere (de) serializzate e caricate anche. In pratica, serializzare i numeri di indice e allegare un elenco indicizzato dei BLOB bytecode sarebbe probabilmente il più efficiente.

Penso che finché si compilano i moduli da soli, questo è già possibile al momento.

Come ho già detto, non sarebbe molto carino. Per non parlare del rischio generalmente elevato di sicurezza per la serializzazione del codice da fonti non sicure da eseguire in un ambiente non protetto. :-)
(Nessun problema se è affidabile, ovviamente.)

Non ho intenzione di codificarlo proprio qui, proprio ora però. ;-)