Могут ли функции Haskell быть сериализованы?

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

Ближе всего к дизайну и внедрению пришел Йост Бертольд, который реализовал сериализацию функций в Eden. См. Его документ IFL 2010 "Ортогональная сериализация для 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

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

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

Ответ 3

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

Ответ 4

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

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

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

  • сохранение неоценимой работы для более позднего
  • распространение работы (но не обмен новым кодом)

Ответ 5

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

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

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

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

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