Как я понимаю, GHC (компилятор Glorious Glasgow Haskell) компилирует Haskell в "Core", а затем компилирует этот Core в машинный код. Будет ли вообще целесообразно распространять программы Haskell в качестве ядра GHC, как если бы это был "байт-код"? Будет ли какая-либо польза от такого распределения? Почему или почему нет?
GHC Core как "байт-код"?
Ответ 1
Это было бы непрактично; GHC Core не переносится. Например, на 32-битной машине 64-разрядная арифметика скомпилирована до вызовов внешних функций в Core, но на 64-битной машине она использует собственную арифметику машинного слова.
Что еще более важно, GHC не может действительно читать Core; он может распечатать его в нескольких форматах, но нет реального кода для чтения любого из этих форматов. Я не уверен, будет ли какое-либо серьезное препятствие для этого, но это была документально зафиксированная ситуация на протяжении многих лет, поэтому я не ожидал, что поддержка появится в ближайшее время.
Core также очень близок к Haskell в целом; это не ясно, что вы купили бы от распространения кода в этой форме. Время, затрачиваемое на то, чтобы превратить Haskell в Core, обычно будет меньше времени, необходимого для того, чтобы делать такие вещи, как ссылка на финальную программу, поэтому обычно не будет экономить время компиляции вообще.
Кроме того, меньшее количество проверок делается на Core, чем на исходный код Haskell (хотя я думаю, что -dcore-lint смягчит это), а песочница будет эффективно (там Safe Haskell, но без безопасного ядра). Конечно, эти недостатки не применяются, если источнику байткода доверяют.
В принципе, GHC Core - это очень простой промежуточный язык компилятора, в отличие от портативных форматов байт-кода, предназначенных для этой цели, таких как байт-код Python и JVM.
В качестве примечания стороны GHC имеет интерпретатор байт-кода, используемый GHCi. Используемый там байт-код также не переносится, поэтому нет никаких преимуществ, которые я могу представить по сравнению с машинным кодом, который GHC производит при нормальной работе.