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