f# - programacion - son los encargados de que los programas compilados en java corran en cualquier sistema operativo

¿Cuál es la forma más fácil de compilar un compilador F#que se ejecuta en la JVM y genera bytecode de Java? (6)

El compilador F # actual está escrito en F #, es de código abierto y se ejecuta en .Net y Mono, lo que le permite ejecutarlo en muchas plataformas, incluidas Windows, Mac y Linux. El mecanismo de Citas de Código de F # se ha utilizado para compilar F # a JavaScript en proyectos como WebSharper , Pit y FunScript . También parece haber cierto interés en ejecutar el código F # en la JVM .

Creo que una versión del compilador OCaml se usó originalmente para Bootstrap el compilador F #.

Si alguien quisiera construir un compilador F # que se ejecute en la JVM, sería más fácil:

¿Modificar el compilador F # existente para emitir bytecode Java y luego compilar el compilador F # con él?
¿Usa un compilador ML basado en JVM como Yeti para Bootstrap, un compilador F # mínimo en la JVM?
¿Reescribió el compilador F # desde cero en Java cuando el proyecto del fjord parece estar intentando?
¿Algo más?

¿Modificar el compilador F # existente para emitir bytecode Java y luego compilar el compilador F # con él? ¿Usa un compilador ML basado en JVM como Yeti para Bootstrap, un compilador F # mínimo en la JVM?

Portar el compilador no debería ser tan difícil si está escrito en F #.

Probablemente iría de la primera manera, porque esta es la única forma en que uno podría esperar mantener sincronizado el nuevo compilador con el compilador .net F #.

¿Reescribió el compilador F # desde cero en Java cuando el proyecto del fiordo parece estar intentando?

Este es ciertamente el enfoque menos elegante, en mi humilde opinión.

¿Algo más?

Cuando termine el compilador, tendrá 90% del trabajo por hacer.

Por ejemplo, no saber mucho F #, pero supongo que es fácil usar cualquier biblioteca .NET por ahí. Eso significa que el problema básico es portar el ecosistema .NET, de alguna manera.

Estaba buscando algo en líneas similares, aunque era más como un traductor / compilador de F # a Akka. En lo que se refiere a F # -> JVM, encontré dos opciones que no estaban preparadas para producción:

1. F# -> [Fjord][1] -> JVM. 2. F# -> [Funscript][2] -> [Vert.X][3] -> JVM

Hay un proyecto que compila OCaml en la JVM, OCaml-Java : es bastante completo y, en particular, puede compilar las fuentes del compilador de OCaml (escritas en OCaml). No estoy seguro de qué aspectos del lenguaje F # le interesan, pero si está buscando principalmente obtener un lenguaje funcional maduro y estrictamente tipado para la JVM, esa puede ser una buena opción.

Otra opción que probablemente debería considerarse es convertir el código de byte .NET CLR en código de byte JVM como http://www.ikvm.net lo hace con los códigos de byte JVM> CLR. Aunque este enfoque ha sido considerado y rechazado por el dueño del fiordo .

Obtener buy-in desde la parte superior con la opción 1) y hacer que el equipo compilador de F # tenga backends conectables que podrían emitir sonidos de byte Java en teoría, ya que produciría la solución más pulida.

Pero si observa otros idiomas que han sido portados a diferentes plataformas, esto rara vez es el caso. La mayoría de las veces ha sido una reescritura desde cero. Pero también es probable que esto se deba a que el equipo de idioma original no tiene interés en respaldar plataformas alternativas y que la implementación del host original podría no haber sido capaz de soportar múltiples backends y ya es demasiado lento para que sea una opción factible para comenzar. .

Mi corazonada es una combinación de reescribir desde cero y poder hacer la mayor cantidad posible de código compartido y automatización desde la implementación original. Por ejemplo, si las suites de prueba pudieran reutilizarse para ambas implementaciones, se eliminaría una gran parte de la carga del puerto JVM y se lograría un gran avance para garantizar la paridad lingüística.

Si realmente tuviera que hacer esto, probablemente comenzaría con el enfoque n. ° 1: agregar el backend de JVM al compilador existente. Pero también trataría de argumentar a favor de una VM objetivo diferente.

Las citas no son muy relevantes. Como autor de WebSharper, puedo asegurarle que aunque las citas pueden ofrecerle un buen lenguaje similar a F # para programar, son restrictivas y no están optimizadas. Me imagino que para los posibles usuarios de JVM F #, la barra sería mucho más alta: compatibilidad completa con el lenguaje y un rendimiento comparable. Esto es muy difícil.

Tome llamadas de cola, por ejemplo. En WebSharper aplicamos la heurística para optimizar algunas llamadas de cola locales a bucles en JavaScript, pero eso no es suficiente: en general, no puede confiar en TCO, como lo hace en las bibliotecas F # generales. Esto está bien para WebSharper ya que nuestros usuarios no esperan tener un F # completo, pero no estará bien para un puerto JVM F #. Creo que la mayoría de las implementaciones de JVM no hacen TCO, por lo que tendrán que implementarse con alguna indirección, introduciendo un golpe de rendimiento.

Un enfoque de recompilación de bytecode mencionado por @mythz suena muy atractivo, ya que permite algo más que simplemente migrar F #, idealmente permite transportar más software .NET a la JVM. Trabajé bastante con el análisis de bytecode .NET en un proyecto interno de WebSharper 3.0. Estamos estudiando la opción de compilar .NET bytecode en lugar de F # quotes en JavaScript. Pero hay grandes desafíos allí:

Una gran cantidad de código en BCL es opaco (nativo) y no se puede descompilar
El modelo genérico es bastante complicado. Implementé un tiempo de ejecución de JavaScript que modela genéricos de clases y métodos, creación de instancias, generación de tipos y reflexión básica con cierta precisión y un rendimiento razonable. Esto era bastante difícil en JavaScript dinámico con cierres y parece bastante difícil de hacer de una manera efectiva en la JVM, pero tal vez simplemente no veo una solución simple.
Los tipos de valor crean complicaciones significativas en el bytecode. Todavía tengo que resolver esto para WebSharper 3.0. Tampoco se pueden ignorar, ya que muchas bibliotecas las utilizan de forma extensiva.
De manera similar, la reflexión básica se usa en muchas bibliotecas .NET del mundo real, y es una pesadilla hacer una compilación cruzada en términos de muchos códigos nativos y soporte adecuado para genéricos y tipos de valores.

Además, el enfoque de bytecode no elimina la pregunta sobre cómo implementar las llamadas de cola. AFAIK, Scala no implementa tailcalls. Ciertamente tienen el talento y la financiación para hacerlo; el hecho de que no lo hagan, me dice mucho sobre lo práctico que es hacer TCO en la JVM. Para nuestro puerto .NET-> JavaScript, probablemente siga una ruta similar: no hay garantías de TCO a menos que solicite específicamente trampolín, lo que funcionará pero le costará un orden de magnitud (o dos) en el rendimiento.

Sospecho que cualquier enfoque sería mucho trabajo, pero creo que su primera sugerencia es la única que evitaría introducir muchas incompatibilidades e insectos adicionales. El compilador es bastante complejo y hay muchos casos de esquina en torno a la resolución de sobrecarga, etc. (y la especificación probablemente también tenga vacíos), por lo que parece poco probable que una nueva implementación tenga una semántica compatible.