sobre - if en haskell ejemplos
¿Se pueden serializar las funciones de Haskell? (5)
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.
La mejor manera de hacerlo sería obtener la representación de la función (si se puede recuperar de alguna manera). La serialización binaria es preferida por razones de eficiencia.
Creo que hay una manera de hacerlo en Clean, porque sería imposible implementar iTask, que se basa en que las tareas (y por lo tanto las funciones) se pueden guardar y continuar cuando el servidor se está ejecutando nuevamente.
Esto debe ser importante para los cálculos distribuidos de Haskell.
No estoy buscando analizar el código haskell en tiempo de ejecución como se describe aquí: Serialización de funciones en Haskell . También necesito serializar no solo deserializar.
Eden probablemente se acerca más y probablemente se merece una respuesta separada: (De-) Serialización de thunks no evaluados es posible, consulte packman .
Sin embargo, la deserialización está limitada al mismo programa (donde el programa es un "resultado de compilación"). Como las funciones se serializan como punteros de código, las funciones previamente desconocidas no se pueden deserializar.
Posible uso:
- almacenar trabajo no evaluado para más tarde
- distribuir trabajo (pero no compartir código nuevo)
Lamentablemente, no es posible con el sistema de tiempo de ejecución ghc actual. La serialización de funciones y otros datos arbitrarios requiere un poco de soporte de tiempo de ejecución de bajo nivel que los ejecutores de ghc han sido reacios a agregar.
Las funciones de serialización requieren que pueda serializar cualquier cosa, ya que los datos arbitrarios (evaluados y no evaluados) pueden ser parte de una función (por ejemplo, una aplicación parcial).
No. Sin embargo, el proyecto CloudHaskell está impulsando la necesidad de soporte de serialización de cierre explícito 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 Template Haskell de la manera que Thomas describe a continuación .
La limitación es la falta de soporte estático en GHC, para el cual hay un ticket de GHC actualmente no activado. (¿Ningún arrendatario?). Se ha debatido en la lista de correo de CloudHaskell acerca de cómo debería ser el soporte estático, pero hasta ahora no se ha avanzado nada.
Lo más cerca que alguien ha llegado a un diseño e implementación es Jost Berthold, quien ha implementado la serialización de funciones en Eden. Vea su documento de IFL 2010 "Serialización ortogonal para Haskell" . El soporte de serialización está integrado en el sistema de tiempo de ejecución de Eden. (Ahora disponible como biblioteca separada: packman . No estoy seguro de si se puede usar con GHC o si necesita un GHC parcheado como en la bifurcación de 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
Entonces: uno puede serializar funciones y estructuras de datos. Hay una instancia Binary para Serialized a , lo que le permite hacer un punto de control de un cálculo de larga duración al archivo. (Ver Secion 4.1).
El soporte para una API de serialización tan simple en las bibliotecas base de GHC seguramente sería el Santo Grial para la programación distribuida de Haskell. Probablemente simplificaría la CloudHaskell MetaPar entre los sabores distribuidos de Haskell ( CloudHaskell , MetaPar , HdpH , Eden , etc.).
Una solución bastante simple y práctica, pero quizás 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 cada vez que se requiera la serialización de esa función, y usar el paquetes de dynamic-loader o plugins , para cargarlos dinámicamente, de modo que se pueden usar incluso funciones previamente desconocidas.
Como un módulo toma nota de todas sus dependencias, esas podrían ser (de) serializadas y cargadas también. En la práctica, serializar números de índice y adjuntar una lista indexada de los blobs de bytecode probablemente sería el más eficiente.
Creo que siempre que compile los módulos usted mismo, esto ya es posible en este momento.
Como dije, no sería muy bonito sin embargo. Sin mencionar el riesgo de seguridad en general enorme de deserializar el código de fuentes inseguras para que se ejecute en un entorno no seguro. :-)
(No hay problema si es confiable, por supuesto)
No voy a codificarlo aquí, sin embargo, ahora mismo. ;-)