¿Se pueden serializar las funciones de Haskell?

No. Sin embargo, el proyecto CloudHaskell está impulsando la necesidad de soporte explícito de serialización de cierre en GHC. Lo más cercano que CloudHaskell tiene a los cierres explícitos es el paquete distributed-static. Otro intento es la representación de cierre HdpH. Sin embargo, ambos usan la Plantilla Haskell de la manera que Thomas describe a continuación.

La limitación es la falta de soporte estático en GHC, para lo cual hay un ticket GHC actualmente no activado . (Cualquier ¿tomadores?). Ha habido una discusión en la lista de correo de CloudHaskell sobre cómo debería ser realmente el soporte estático, pero nada ha progresado hasta donde yo sé.

Lo más cercano que alguien ha llegado a un diseño e implementación es Jost Berthold, quien ha implementado la serialización de funciones en Eden. See his IFL 2010 paper "Orthogonal Serialisation for Haskell". El soporte de serialización se integra en el sistema Eden runtime. (Ahora disponible por separado biblioteca: packman . No estoy seguro de si se puede usar con GHC o necesita un GHC parcheado como en la bifurcación Eden...) Algo similar sería necesario para GHC. Este es el soporte de serialización Eden, en la versión bifurcada de GHC 7.4:

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

Así que: uno puede serializar funciones y estructuras de datos. Hay una instancia Binary para Serialized a, lo que le permite comprobar un cálculo de larga duración para archivar! (Véase Sección 4.1).

Soporte para una API de serialización tan simple en las bibliotecas base de GHC seguramente serían el Santo Grial para la programación distribuida de Haskell. Es probable que simplificar la composability entre distribuido Haskell sabores (CloudHaskell, MetaPar, HdpH, Eden y así sucesivamente...)

Echa un vistazo a Cloud Haskell. Tiene un concepto llamado Closure que se utiliza para enviar código para ser ejecutado en nodos remotos de una manera segura de tipo.

Eden probablemente se acerca más y probablemente merece una respuesta separada: (Des-)La serialización de los thunks no evaluados es posible, ver https://github.com/jberthold/packman .

Sin embargo, la deserialización está limitada al mismo programa (donde programa es un "resultado de compilación"). Dado que las funciones son serializadas como punteros de código, las funciones previamente desconocidas no pueden ser deserializadas.

Posible uso:

• almacenar el trabajo no evaluado para más adelante
• distribución trabajo (pero sin compartir código nuevo)

Una solución bastante simple y práctica, pero tal vez no tan elegante sería (preferiblemente tener GHC automáticamente) compilar cada función en un módulo separado de bytecode independiente de la máquina, serializar ese bytecode siempre que se requiera serialización de esa función, y usar los paquetes dynamic-loader o plugins, para cargarlos dinámicamente, por lo que incluso se pueden usar funciones previamente desconocidas.

Dado que un módulo toma nota de todas sus dependencias, éstas podrían ser (des)serializadas y cargadas también. En la práctica, serializar los números de índice y adjuntar una lista indexada de los blobs de bytecode probablemente sería la más eficiente.

Creo que mientras compile los módulos usted mismo, esto ya es posible en este momento.

Como dije, no sería muy bonito. Sin mencionar el riesgo de seguridad generalmente enorme de des-serializar código de fuentes inseguras para ejecutarse en un entorno no seguro. :-)
(No hay problema si es confiable, por supuesto.)

No voy a codifícalo aquí mismo, ahora mismo. ;-)