Насколько безопасен Haskell?

Я думал о Safe Haskell, и мне интересно, насколько я могу доверять ему?

Некоторые вымышленные сценарии:

Я немного хакер, пишущий программируемую игру (думаю Robocode), где я разрешаю другим программировать свои собственные сущности, чтобы конкурировать друг с другом. Большую часть времени пользователи будут запускать некоторые ненадежные программы на частных машинах. Неверный код, вероятно, будет проверен перед его запуском.
Я программист приложения, которое используется несколькими клиентами. Я предоставляю api, чтобы они могли расширить функциональность и побудить моих пользователей делиться своими плагинами. Сообщество пользователей небольшое, и большую часть времени существует взаимное доверие, но иногда кто-то работает над совершенно секретным проектом клиента, и любые dataleaks оказались бы катастрофическими.
Я... Google (или Facebook, Yahoo и т.д.) и хочу разрешить моим клиентам script их учетные записи электронной почты. Скрипты загружаются и запускаются на моих серверах. Любые нарушения доступа будут фатальными.

Учитывая эти сценарии:

Безопасный Haskell должен быть подходящим для обеспечения песочницы и ограничения доступа?
Если кто-то в данных ситуациях может доверять promises?

Ответ 1

Как правило, я бы сказал, что безопасный Haskell пытается грубо найти безопасное подмножество С#. Для ваших сценариев:

Можно использовать безопасный haskell, потому что вы проверяете код.
Нельзя использовать безопасный хакелл в одиночку, чтобы избежать катастрофических утечек данных.
Я бы не рекомендовал Google или Yahoo полагаться только на безопасный хакелл для запуска ненадежного кода. Во-первых, он не справляется с чрезмерным потреблением ресурсов (процессор, память, диск) или днище (undefined или while). Для этого используйте изолированную среду ОС.

Заметка на undefined: оперативно она останавливает функцию, возвращающую значение, вызывая исключение, также как и функция ошибки. Обоснованно он считается "нижней" величиной. Теперь, даже если безопасный Haskell запретил undefined и ошибку, функция все равно не сможет вернуться, просто зацикливаясь бесконечно. И бесконечный цикл - тоже дно. Таким образом, безопасный Haskell гарантирует безопасность и безопасность памяти, но не пытается гарантировать, что функции прекратятся. Safe Haskell, конечно же, Тьюринг завершен, поэтому вообще невозможно доказать прекращение. Кроме того, поскольку внешняя память генерирует исключение, функции могут заканчиваться с ними. Наконец, ошибки совпадения шаблонов вызывают исключения. Таким образом, безопасный Haskell не может устранить нижние части любого типа и может также допускать явные undefined и ошибки.

Ответ 2

Насколько я знаю, безопасный Haskell небезопасен. Кто-то может использовать unsafePerformIO в пакете и вручную переопределять "небезопасный" фактор. Если нет, каждый пакет, который имел какие-либо зависимости от c-программ или системных библиотек, не мог быть помечен безопасным. (Подумайте о libgmp.so, к которому привязаны почти все базовые пакеты Haskell. Для того, чтобы базовые пакеты были помечены безопасно, это должно быть как-то явно помечено как безопасное, даже если оно использует unsafePerformIO).