¿Qué tan práctico es portar una aplicación Common Lisp a Clojure? Para ser más específico, ¿qué características existen en Common Lisp que no existen en Clojure y que deberían ser reescritas?Transmitiendo el código Common Lisp a Clojure
Hay un list on clojure.org de diferencias entre Clojure y otros Lisps. Algunas otras cosas que he notado al usar Clojure:
Idiomatic Clojure se inclina fuertemente hacia las estructuras de datos inmutables. En cualquier lugar que vea SETF en CL, deberá cambiarse en Clojure para aprovechar al máximo. (Siempre tiene la opción de utilizar estructuras de datos Java mutables en Clojure, pero la mayoría de las personas no).
Los métodos de Clojure son similares a los de CL (posiblemente más potentes, ya que puede enviarlos a otras cosas que no sean de tipo), pero un CLOS en toda regla no está disponible en Clojure. En cambio, Clojure usa struct, que es simplemente un hashmap elegante. El sistema OOP de Java también está disponible, por supuesto. Algunas personas están trabajando en portar CLOS a Clojure, pero no estoy seguro de qué tan avanzado están esos esfuerzos en este punto.
Las macros Clojure funcionan de forma ligeramente diferente que las macros CL cuando se trata de la resolución de símbolo/espacio de nombres. No estoy seguro si entiendo lo suficiente como para dilucidar las diferencias. Sin embargo, en Clojure no tienes que meterte con los gensimos tanto, lo cual es bueno.
Clojure no tiene un sistema de condición como CL's. Solo tiene el try/catch/finally de Java para el manejo de excepciones.
Clojure no permite las macros de lector definidas por el usuario.
Clojure no tiene valores de retorno múltiples. La desestructuración en Clojure es muy buena (admite listas, vectores, hash-maps, conjuntos, etc.) y está incorporada en más lugares que CL de forma predeterminada, por lo que este es un problema menor de lo que podría ser.
Dependiendo de la aplicación y la forma en que está escrito, puede ser práctico y directo al puerto de CL a Clojure, o puede ser más práctico volver a escribir desde cero de una manera más funcional, seguro para subprocesos forma de encajar mejor con el estilo Clojure.
no tengo una respuesta específica, pero recomiendo estos recursos:
No creo que el trabajo sea de Peter Seibel. Stuart Halloway es el que transporta de CL a Clojure. –
Gracias, Brian. Fijo. Acabo de comprar la preimpresión de Stuart, así que tal vez me perdone :) – zweiterlinde
Hay un número de cuentas de la transición de CL a Clojure (blog, another blog, Thread on HN).
El mayor problema que muchos de los Lisios comunes tienen con Clojure cuando lo comprueban es su falta de optimización de llamada de cola, que no es posible en la JVM.
Es por eso que utilizas recurrir en su lugar. –
y trampolines también. Sin embargo, ha habido algún progreso en la obtención de TCO en la JVM a través del proyecto OpenJDK. – dnolen
Muchas CL tampoco lo hacen (no es obligatorio), y no conozco ningún programa (mers) que dependa de él. por ejemplo, SBCL/CMUCL no lo hace a menos que use la optimización de espacio dinámico. – Ken
Para el código CL idiomático es una reescritura.
Incluso portar la infraestructura necesaria (CLOS, Error Handling, Streams) a Clojure tiene poco sentido, ya que Clojure es realmente un idioma diferente con un estilo de programación diferente.
Si no se desea reescribir el código, existe por ejemplo ABCL, que es un Lisp común para la JVM.
También Clojure es un Lisp 1 (con espacios de nombres), mientras que CL es un Lisp 2. Esta es una diferencia muy importante que afecta enormemente a las macros y, en menor grado, a las declaraciones de variables y funciones. – dsm
Las macros de Clojure están más cerca de las CL que las de Scheme. Las macros de Clojure no son higiénicas, pero hacen que sea mucho más fácil ser higiénico por defecto. –
Los multimétodos de CLOS pueden enviarse por tipo o identidad. ¿Qué más puede enviar Clojure? –