Jak rozumiem, GHC (Glorious Glasgow Haskell Compiler) kompiluje Haskella do "Core", a następnie kompiluje ten Core do kodu maszynowego. Czy rozpowszechnianie programów Haskell jako GHC Core byłoby całkowicie praktyczne, tak jakby były "bajtodami"? Czy będzie jakaś korzyść z takiej dystrybucji? Dlaczego lub dlaczego nie?GHC Core jako "kod bajtowy"?
To nie byłoby praktyczne; GHC Core nie jest przenośny. Na przykład na maszynie 32-bitowej 64-bitowa arytmetyczna jest kompilowana do wywołań funkcji obcych w rdzeniu, ale na maszynie 64-bitowej używa natywnej arytmetyki maszynowej.
Co ważniejsze, GHC nie może faktycznie przeczytać Rdzeń; może wydrukować go w kilku formatach, ale nie ma rzeczywistego kodu, który odczytałby któryś z tych formatów. Nie jestem pewien, czy byłaby jakaś poważna przeszkoda, ale jest to udokumentowana sytuacja od wielu lat , więc nie spodziewałbym się, że wsparcie pojawi się w najbliższym czasie.
Rdzeń jest również bardzo zbliżony do Haskella w ogóle; nie jest jasne, co można kupić za dystrybucję kodu w tym formularzu. Czas potrzebny na przekształcenie Haskella w Rdzeń jest zwykle krótszy niż czas potrzebny na połączenie końcowego programu, więc zazwyczaj nie oszczędziłoby to w ogóle czasu kompilacji.
Ponadto, mniej sprawdzania jest wykonywane dla kodu źródłowego niż kodu źródłowego Haskella (chociaż myślę, że -dcore-lint złagodziłoby to), a jego efektywne działanie byłoby trudne (jest Safe Haskell, ale nie ma Safe Core). Oczywiście te wady nie mają zastosowania, jeśli źródło kodu bajtowego jest zaufane.
Zasadniczo GHC Core jest bardzo pośrednim językiem kompilatora, w przeciwieństwie do przenośnych formatów bajtowych zaprojektowanych do tego celu, takich jak kod bajtowy Python i JVM.
Na marginesie, GHC ma ma interpreter kodu bajtowego, jak używane przez GHCi. Użyty tam kod bajtowy jest również nieprzenośny, więc nie ma żadnych korzyści, jakie mogę wymyślić w porównaniu do kodu maszynowego, jaki GHC wytwarza podczas normalnej pracy.