¿En qué orden deben definirse las funciones lisp?

8

¿En qué orden se debe organizar el código en un solo archivo lisp? ¿Existe alguna pauta de estilo común que permita a otros programadores lisp entender fácilmente el código?

Googlear para pauta de estilo lisp produce muchos resultados; entre ellos:

Sin embargo, parece que no se discute cómo deben organizarse las funciones y otras definiciones dentro de un único archivo fuente.

"Clean Code" por Martin Fowler (que no está específicamente dirigido a Lisp) recomienda organizar funciones / métodos de arriba a abajo: primero describiendo el código de manera abstracta y luego profundizando cada vez más en los detalles. Lo que en mi opinión es una buena manera de organizar definiciones de funciones.

Sin embargo, cuando las definiciones de funciones se ordenan de arriba a abajo, el REPL SBCL proporciona caught STYLE-WARNING: undefined function: … al cargar un archivo lisp. Así que aparentemente, SBCL piensa que usar una función antes de definirla es un mal estilo.

¿Cuál es la mejor práctica para el orden de las definiciones? Preferiblemente sin dar como resultado advertencias del compilador / intérprete.

    
pregunta Kasper van den Berg 06.04.2016 - 12:20

2 respuestas

5

Para Common Lisp, estoy usando algo como esto:

  • los archivos están organizados en sistemas y subsistemas (vea, por ejemplo, ASDF como una herramienta para eso)
  • puedes poner todo en un archivo, pero eso tiene mucho cuidado
  • las piezas más grandes de Lisp están organizadas en sistemas de archivos (ver más arriba) y generalmente se compilan con el compilador de archivos
  • utilizando compile-file , un archivo es una unidad de compilación

Archivos en un system:

  1. declaración (es) del sistema
  2. declaraciones de paquetes
  3. funciones de utilidad
  4. macros
  5. clases
  6. varios códigos
  7. código específico de la máquina / OS / implementación
  8. un sistema para pruebas

un subsistema en un archivo:

  1. encabezado del editor (modo, paquete, dialecto, codificación de texto, base, ...)
  2. derechos de autor, licencia
  3. descripción del propósito y uso
  4. usando qué paquete
  5. vars / data de configuración global
  6. constantes
  7. clases principales
  8. clases de condición
  9. macros y su código de soporte
  10. funciones / métodos / funciones genéricas
  11. ejemplos

Si desarrolla, carga el sistema compilado desarrollado hasta el momento y lo amplía de forma incremental. Una vez que se escribe y prueba una nueva funcionalidad - > vuelva a compilar el sistema, cárguelo y pruébelo nuevamente.

El libro antiguo 'Lisp: Estilo y diseño' de Molly M. Miller y Eric Benson describe los principios de organización y da un ejemplo. Dado que este libro es antiguo, hay una infraestructura más nueva y algunas herramientas nuevas. Pero los principios generales mencionados en el libro siguen siendo útiles.

    
respondido por el Rainer Joswig 06.04.2016 - 17:27
3

Common Lisp tiene COMPILE y COMPILE-FILE .

Una implementación como SBCL no advierte sobre una función no definida si compila todo el archivo, por ejemplo. Bajo el limo, C-c M-k no activa una advertencia:

(defun bar (x) (foo x))
(defun foo (y) (+ 3 y))

Una vez que se compila, la carga del .fasl en una imagen Lisp nueva tampoco da ninguna advertencia, aunque la carga del .lisp sí lo hace, porque LOAD para un archivo fuente simplemente ejecuta todos los formularios en secuencia.

Sin embargo, la mayoría de los códigos que vi definen cosas de elementos de bajo nivel y crean funciones de nivel superior más adelante en el archivo. No me parece más confuso en ese orden que en el reverso, personalmente. Es bastante consistente con la forma en que define las funciones locales con flet o labels , o incluso las variables locales con let . Si necesita definir funciones recursivas entre sí, también puede declarar sus funciones antes de definirlas:

(declaim (ftype function foo bar baz ...))

El entorno Lisp admite formas eficientes de ir a la definición de funciones y métodos, por lo que generalmente confío más en slime-edit-definition .

Lo más importante para la organización de su código de IMO es probablemente pensar en los paquetes y cómo se relacionan entre sí.

    
respondido por el coredump 06.04.2016 - 13:33

Lea otras preguntas en las etiquetas