Могут ли функционировать функции Haskell?

Question

Лучший способ сделать это - получить представление функции (если ее можно каким-то образом восстановить). По соображениям эффективности предпочтительна двоичная сериализация.

Я думаю, что есть способ сделать это в Чистом, потому что было бы невозможно реализовать iTask, который опирается на эти задачи (и поэтому функции) можно сохранить и продолжить, когда сервер снова запустится.

Это должно быть важно для распределенных вычислений haskell.

Я не ищу синтаксический анализ кода haskell во время выполнения, как описано здесь: Serialization of functions in Haskell. Мне также нужно сериализовать не только десериализацию.

Answer 1

К сожалению, это невозможно в текущей системе исполнения ghc. Сериализация функций и других произвольных данных требует некоторой поддержки времени выполнения, которую разработчики ghc неохотно добавляют.

Сериализация функций требует, чтобы вы могли сериализовать что угодно, поскольку произвольные данные (оцениваемые и неоцениваемые) могут быть частью функции (например, частичного приложения).

Answer 2

Отъезд Cloud Haskell. Он имеет концепцию Closure, которая используется для отправки кода, который должен выполняться на удаленных узлах безопасным образом.

Answer 3

Нет. Однако проект CloudHaskell ведет домой необходимость явной поддержки сериализации закрытия в GHC. Ближайшей областью CloudHaskell для явных закрытий является пакет distributed-static. Другая попытка - HdpH closure representation. Тем не менее, оба используют шаблон Haskell в способе Thomas describes below.

Ограничение - это отсутствие статической поддержки в GHC, для которой в настоящее время действует без изменений GHC ticket. (Любые берущие?). В списке рассылки CloudHaskell было a discussion о том, какая статическая поддержка должна на самом деле выглядеть, но пока ничего не произошло, насколько я знаю.

Ближайшим, кто пришел к дизайну и реализации, является Йост Бертольд, который реализовал сериализацию функций в Эдеме. См. Его документ IFL 2010 "Orthogonal Serialisation for Haskell". Поддержка сериализации используется в системе исполнения Eden. (Теперь доступна как отдельная библиотека: packman. Не уверен, может ли он использоваться с GHC или нужен пропатченный GHC, как в вилке Eden ...). Что-то подобное было бы необходимо для GHC. Это поддержка сериализации Eden, в версии раздвоенной от GHC 7.4:

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

Итак: один может сериализовать функции и структуры данных. Существует Binary экземпляр для Serialized a, что позволяет вам проверять долговременное вычисление на файл! (См. Раздел 4.1).

Поддержка такого простого API-интерфейса сериализации в базовых библиотеках GHC, несомненно, была бы святым Граалем для распределенного программирования Haskell. Это, скорее всего, упростить компонуемости между распределенными вкусами Haskell (CloudHaskell, MetaPar, HdpH, Eden и так далее ...)

Answer 4

Eden, вероятно, ближе всего и, вероятно, заслуживает отдельный ответа: (Де-) Сериализация невычисленных санков является возможно, см. https://github.com/jberthold/packman.

Однако десериализация ограничена одной и той же программой (где программа является «результатом компиляции»). Поскольку функции сериализуются как указатели кода, ранее неизвестные функции нельзя десериализовать.

Возможное использование:

• хранения невычисленного работы для последующего
• распределения работы (но не разделение нового кода)

Answer 5

Довольно простой и практичный, но, возможно, не столь элегантное решение (желательно иметь GHC автоматически) скомпилировать каждую функцию в отдельный модуль машинного независимого байт-кода, сериализуйте этот байт-код всякий раз, когда требуется сериализация этой функции, и используйте dynamic-loader или plugins, чтобы динамически загружать их, поэтому можно использовать даже ранее неизвестные функции.

Поскольку модуль отмечает все свои зависимости, они могут быть (де) сериализованы и загружены тоже. На практике сериализация индексных номеров и привязка индексированного списка блочных байт-кодов, вероятно, были бы наиболее эффективными.

Я думаю, что до тех пор, пока вы сами компилируете модули, это уже возможно прямо сейчас.

Как я уже сказал, это было бы не очень красиво. Не говоря уже об огромном угрозе безопасности для де-сериализации кода из небезопасных источников для работы в незащищенной среде. :-)
(Нет проблем, если это заслуживает доверия, конечно.)

Я не собираюсь кодировать его прямо здесь, прямо сейчас. ;-)