Như tôi đã hiểu, GHC (Trình biên dịch Haskell Glorious Glasgow) biên dịch Haskell thành "Lõi", và sau đó biên dịch Lõi đó thành mã máy. Nó sẽ được ở tất cả các thực tế để phân phối các chương trình Haskell như GHC Core, như thể nó là "bytecode"? Sẽ có bất kỳ lợi ích nào cho phân phối như vậy không? Tại sao hay tại sao không?GHC Core là "bytecode"?
Điều này sẽ không thực tế; GHC Core không di động. Ví dụ, trên một máy 32 bit, số học 64 bit được biên dịch xuống các cuộc gọi hàm ngoài trong lõi, nhưng trên một máy tính 64 bit, nó sử dụng số học từ máy bản địa.
Quan trọng hơn, GHC không thể thực sự đọc Core; nó có thể in ra trong một vài định dạng, nhưng không có mã thực sự để đọc bất kỳ định dạng nào trong đó. Tôi không chắc liệu sẽ có trở ngại lớn nào để làm như vậy, nhưng đó là tình huống được ghi nhận trong nhiều năm , vì vậy tôi không mong đợi sự hỗ trợ xuất hiện sớm.
Lõi cũng khá gần với Haskell nói chung; nó không rõ ràng những gì bạn muốn mua từ mã phân phối trong hình thức đó. Thời gian cần để biến Haskell thành Core thường ít hơn thời gian để làm những việc như liên kết chương trình cuối cùng, vì vậy thường thì nó sẽ không tiết kiệm được nhiều thời gian biên dịch.
Ngoài ra, ít kiểm tra được thực hiện với Core hơn mã nguồn Haskell (mặc dù tôi nghĩ rằng -dcore-lint sẽ giảm thiểu điều này) và hộp cát có hiệu quả sẽ rất khó (có Haskell an toàn, nhưng không có lõi an toàn). Tất nhiên, những nhược điểm này không áp dụng nếu nguồn gốc của bytecode được tin cậy.
Về cơ bản, GHC Core là ngôn ngữ trung gian của trình biên dịch, ngược lại với các định dạng bytecode di động được thiết kế cho mục đích, như mã byte bytecode và JVM.
Lưu ý phụ, GHC không có trình thông dịch bytecode, như được sử dụng bởi GHCi. Bytecode được sử dụng ở đó cũng không di động, vì vậy không có lợi thế nào tôi có thể nghĩ đến so với mã máy GHC tạo ra trong hoạt động bình thường.