Что мешает эффективной виртуальной машине Haskell (например, JVM)?

Мне было интересно, что мешает разработке эффективной виртуальной машины, такой как JVM или PyPy для Haskell (кроме, может быть, усилий по разработке)? Это языковая структура? Я думаю, что языки, которые сложнее интерпретировать эффективно (например, Python, будучи очень динамичными), уже имеют приличные виртуальные машины.

Кроме того, если ничего не мешает такой реализации, будет ли STG хорошей целевой "байт-код", поскольку все оптимизации выполняются на Core?

Есть ли какие-либо статьи или сообщения в блогах, которые обсуждают эту тему?

редактирует:

Я знаю HaLVM, но я не думаю, что это то, что я имею в виду.
Я также знаю runhaskell, но он неэффективен вообще.

Ответ 1

Что мешает эффективной виртуальной машине Haskell?

Ничего - там уже был один, Daan Leijen LVM. Это было достаточно эффективно для использования во время работы системы гелия (язык обучения "Хаскелл" из Университета Утрехта).

Это говорит, что я не знаю, используется ли это в наши дни, поэтому вопрос "Что мешает эффективной виртуальной машине Haskell?" можно ответить как трудовые ресурсы, непрерывные инвестиции и т.д. Когда у Haskell уже есть хороший компилятор, хорошая виртуальная машина - это роскошь, о которой уже говорил Пауло Пинто.

Ответ 2

У меня нет возможности опубликовать комментарий, и это, возможно, даже больше анти-VM, чем компилятор с собственным кодом, но OP может быть заинтересован в Reduceron.

Ответ 3

UHC имеет бэкэнд Javascript, который, конечно же, работает в браузере Javascript. Я имею в виду, что я не вижу ничего, что останавливало бы Haskell от таргетинга на разные серверы. На самом деле, я думаю, UHC был разработан, чтобы облегчить таргетинг на разные серверы.

Ответ 4

Я не знаю никаких технических ограничений, применяемых здесь. Существует язык, называемый Frege, семантически близкий к Haskell, который предназначен для JVM. Таким образом, никто до сих пор не рассмотрел, что компилятор Haskell-JVM стоит того. Действительно, как JVM-скептик, мне интересно, что это принесет. Если это просто переносимость на промежуточном языке, я бы предпочел работать с LLVM или на предварительно построенной двоичной ферме.

Ответ 5

Ничего. См. lambdachine. Вот несколько коротких заметок.

Ответ 6

Ничто не мешает Haskell иметь виртуальную машину. Haskell прекрасно работает на JVM и может быть даже быстрее, чем GHC после прогрева JIT, в тех случаях, когда сгенерированный код попадает в сладость JIT-компилятора. См. Eta, проект, который приносит полный GHC 7.10.3 Haskell на JVM с безопасным Java-взаимодействием. Это просто требует много терпения и времени для работы.