Hay Gambit Scheme, Esquema MIT, Esquema PLT, Chicken Scheme, Bigloo, Larceny, ...; luego están todos los ceceos.¿Por qué no hay un buen esquema/lisp en llvm?
Sin embargo, no hay (que yo sepa) un único populares esquema/Lisp en LLVM, a pesar de que LLVM ofrece un montón de cosas interesantes como:
Entonces, ¿por qué no hay un buen esquema/ceceo en LLVM?
LLVM proporciona mucho, pero todavía es solo una pequeña parte del tiempo de ejecución que necesita un lenguaje funcional. Y las llamadas C FFI no son complicadas porque LLVM deja la gestión de la memoria a cargo de otra persona. Interactuar con Garbage Collector es lo que hace que las llamadas de FFI sean difíciles en lenguajes como Scheme.
Puede que le interese el HLVM, pero en este momento es más que experimental.
"más que experimental" :-) –
Hasta donde puedo decir, HLVM está muerto. – dfeuer
No estoy seguro, pero ¿estás diciendo que un recolector de basura [en general] es por lo que es difícil para LLVM, o solo un [recolector de basura para LISP] es demasiado difícil? Porque estoy bastante seguro de que hay idiomas en LLVM con recolectores de basura. Los documentos de LLVM incluso ** mencionan específicamente Scheme. ** http://llvm.org/docs/GarbageCollection.html –
Una cosa a tener en cuenta es que muchas de estas implementaciones tienen C FFIs y compiladores de código nativo que son significativamente anteriores a LLVM.
GHC está experimentando con un backend de esquema y obteniendo resultados preliminares realmente emocionantes sobre su compilador de código nativo. De acuerdo, eso es Haskell. Pero recientemente impulsaron nuevos cambios en LLVM haciendo que las llamadas de cola sean más fáciles IIRC. Esto podría ser bueno para la implementación de algún esquema.
Creo que te refieres al backend de LLVM en lugar de Scheme. – Chuck
¿Cómo se pueden hacer las llamadas de cola más fácilmente? Simplemente marque las llamadas en posición de cola con "cola" y habilite TCO ... –
no hay (que yo sepa) un único esquema de populares/Lisp en LLVM
Actualmente, llvm-gcc es lo más parecido a una aplicación popular de cualquier lenguaje sobre LLVM. En particular, hay no implementaciones maduras basadas en lenguaje LLVM con recolección de basura todavía. Estoy seguro de que LLVM se utilizará como base para muchas implementaciones de idiomas de la próxima generación, pero tomará un lote de tiempo y esfuerzo, y es pronto para LLVM en este contexto.
Mi propia HLVM proyecto es una de las pocas implementaciones basadas en LLVM con la recolección de basura y su GC es de múltiples núcleos con capacidad pero débilmente unida: He utilizado una pila sombra de un "entorno poco cooperativo" en lugar de cortar el código C++ en LLVM para integrar la verdadera pila de caminar.
Actualización: ahora hay una, a saber, Mono. –
También hay Clang hoy en día, y Haskell tiene una implementación de LLVM. Todavía no hay Lisps AFAIK. (No digo que Jon estaba equivocado. Solo estoy proporcionando una actualización.) – Chuck
@ SK-logic: AFAIK, la última vez que miré (Nov 2010) Mono todavía no tenía un recolector de basura que funcionaba y no estoy seguro de cuál es el estado de Mono. ya que sus desarrolladores fueron despedidos. http: //flyingfrogblog.blogspot.com/2010/11/mono-28-step-closer-to-reliable.html –
Hay una muy pequeña y aparentemente unoptimised compilador Esquema aquí:
http://www.ida.liu.se/~tobnu/scheme2llvm/
Tomando su pregunta literalmente,
Creo que podría ser muy divertido para alguien construir un compilador Scheme basado en LLVM. Los compiladores de Scheme en SICP y PAIP son buenos ejemplos.
Link ha muerto, pero aquí está el [archivo más nuevo que pude encontrar] (https://web.archive.org/web/20110226115214/http://www.ida.liu.se/~tobnu/scheme2llvm/) desde febrero de 2011 – Anko
Tal vez estoy malinterpretando por completo la pregunta o el contexto, pero creo que podría usar ECL, que es un Common Lisp que compila hasta C, y usar el compilador Clang para apuntar a LLVM (en lugar de GCC).
No estoy seguro de qué beneficio (si lo hay) que esto le daría, pero le daría un Lisp corriendo en LLVM =].
Totalmente de acuerdo. Creo que ese es el mayor beneficio de ECL sobre Trival Lisp Compiler. –
CL-LLVM proporciona enlaces de Common Lisp para LLVM. Toma el enfoque FFI, en lugar de intentar generar el ensamblaje LLVM o el código de bits directamente.
Esta biblioteca está disponible a través de Quicklisp.
¿Admite la compilación de iOS Xcode moderna? ¿Es realmente utilizable en producción? es decir: ¿es compatible con ARM64 y bitcompiling en iOS? –
Lo siento. No lo sé. No he usado este módulo. He usado [mocl] (https://wukix.com/mocl) que funciona bien. – masukomi
mocl es un compilador para un subconjunto relativamente estático de Common Lisp. Compila a través de LLVM/Clang.
La información sobre MOCL es escasa. ¿Qué "subconjunto estático" de Common Lisp proporciona, precisamente? –
Para CL: Clasp es una implementación Common Lisp en LLVM, y mocl implementa un subconjunto de Common Lisp en LLVM.
Para el esquema: hay un self-hosting Scheme->LLVM demo y a prototype LLVM backend for Bigloo Scheme.
Para Clojure: hay Rhine, que es un ceceo inspirado en Clojure.
¿Esta pregunta está pidiendo respuestas reales, como problemas con LLVM y/o Scheme, ya sean técnicos o sociales, que impiden que se realice esta implementación? O simplemente se queja retóricamente, como "¿Por qué nadie ha cocinado?" o "¿Por qué es este autobús tan tarde?" –