Según tengo entendido, GHC (el Compilador Glorious Glasgow Haskell) compila Haskell para "Núcleo", y luego compila ese Núcleo en código máquina. ¿Sería en absoluto práctico distribuir los programas de Haskell como GHC Core, como si fuera "bytecode"? ¿Habría algún beneficio para tal distribución? ¿Por qué o por qué no?GHC Core como "bytecode"?
Respuesta
Esto no sería práctico; GHC Core no es portátil. Por ejemplo, en una máquina de 32 bits, la aritmética de 64 bits se compila para las llamadas a funciones externas en el Core, pero en una máquina de 64 bits, usa una aritmética nativa de máquina-palabra.
Más importante aún, GHC no puede realmente leer Núcleo; puede imprimirlo en unos pocos formatos, pero no hay un código real para volver a leer ninguno de esos formatos. No estoy seguro de si habría algún obstáculo importante para hacerlo, pero ha sido la situación documentada durante muchos años. , por lo que no esperaría que el soporte aparezca pronto.
Core también es bastante cercano a Haskell en general; no está claro qué comprarías al distribuir código en esa forma. El tiempo que lleva convertir a Haskell en Core generalmente va a ser menor que el tiempo necesario para hacer cosas como vincular el programa final, por lo que normalmente no ahorraría mucho en el tiempo de compilación.
Además, se realiza menos comprobación del código fuente de Core que de Haskell (aunque creo que -dcore-lint
mitigaría esto), y el espacio aislado sería difícil (hay Safe Haskell, pero no Safe Core). Por supuesto, estas desventajas no se aplican si la fuente del bytecode es de confianza.
Básicamente, GHC Core es en gran medida el lenguaje intermedio de un compilador, a diferencia de los formatos de bytecode portátiles diseñados para este propósito, como el bytecode de Python y la JVM.
Como nota al margen, GHC tiene tiene un intérprete de bytecode, como el utilizado por GHCi. El bytecode utilizado allí tampoco es portátil, por lo que no hay ventajas en las que pueda pensar comparado con el código de máquina que GHC produce en el funcionamiento normal.
- 1. Javascript como bytecode depurable
- 2. ¿Es posible transformar el bytecode LLVM en bytecode de Java?
- 3. java bytecode editor?
- 4. Bytecode vs. Interpretado
- 5. Programming in Java bytecode
- 6. Tipos en Bytecode
- 7. Ruby to Actionscript3 Bytecode
- 8. Haskell, GHC, win32, cairo
- 9. Lista de extensiones GHC
- 10. ¿Cómo puedo ayudar a SpecConstr en GHC?
- 11. ¿Los archivos binarios compilados ghc requieren GHC o son autocontenidos?
- 12. GHC 6.12 y MacPorts
- 13. de LLVM para GHC
- 14. Core Image vs Core Graphics
- 15. Compilación cruzada con GHC
- 16. extensiones categorización GHC
- 17. zlib con GHC
- 18. ¿Puede ghc tratar ciertas advertencias especificadas como errores y otras como advertencias?
- 19. ejecutando bytecode jython usando java
- 20. Java: nueva instancia de bytecode
- 21. Java Bytecode Manipulation Library Sugerencias
- 22. Comportamiento diferente de bytecode java
- 23. ¿JAXB utiliza instrumentación de bytecode?
- 24. Especificación de bytecode de Java
- 25. rama no vago de GHC
- 26. Instalación de GHC sin raíz
- 27. Cómo dibujaría algo como esto en Core Graphics
- 28. ¿Está almacenando imágenes en Core Data o como archivo?
- 29. Especifique el arco en GHC?
- 30. Inferencia de tipo GHC infortunios