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