10

Para mí, el Patten intérprete suena muy parecido a un anti-patrón conocido como décima regla de Greenspun:¿El INTÉRPRETE es un antipatrón?

Cualquier programa Fortran C suficientemente complicado o contiene ad hoc, de manera informal especificados por el,, la lenta aplicación plagada de errores de la mitad de Common Lisp.

Es decir, si necesita utilizar el intérprete, es probable que cree algo que sea lento, ad-hoc y mal especificado. La solución correcta es usar el lenguaje correcto desde el principio.

O, como alternativa, inserte un lenguaje bien conocido y bien especificado en su aplicación, como Guile (el esquema embebible GNU). O use Haskell como un lenguaje embebido específico del dominio.

Pero no he visto esto en la práctica: ¿cuáles son sus experiencias con respecto a la creación de sus propios lenguajes incrustados? ¿Es una buena idea? ¿Es mejor que incorporar un idioma ya existente?

(no estoy particularmente un fanboy Lisp. Es agradable, pero por lo de C y Haskell y Python y muchos otros idiomas.)

+3

Hay una escuela de pensamiento que dice que los Smalltalkers entre la Banda de los Cuatro pusieron el Patrón de Intérprete en el libro como una broma, solo para burlarse de la multitud de C++. Desafortunadamente, la multitud de C++ no entendió la broma, y ​​ahora estamos atrapados con eso. (La broma es, por supuesto, que en Smalltalk el programador obtiene acceso de tiempo de ejecución programático completo al compilador e intérprete y, por lo tanto, no hay necesidad de algo así como el Patrón de Intérprete). –

Respuesta

31

No hay nada en el patrón intérprete, que dice que tiene que haber otra programación la sintaxis del idioma que está interpretando. Si necesita analizar una expresión matemática simple, entonces el intérprete es lo correcto.

Saber cuándo usar un patrón es lo que evita que sea un antipatrón.

+9

Casi quiero editar esta publicación solo para agregar énfasis a La última oración. Pero no creo que sea posible agregar tanto énfasis como creo que necesita, así que no voy a molestarme. –

+0

Puede votar por mi respuesta, que es esencialmente la última frase de este: D –

+0

El patrón del intérprete es uno que envejece muy mal (las expresiones matemáticas simples tienden a ser cada vez más complejas hasta que tenga su propia Mathematica). Realmente tendría que pensar en este riesgo al comparar los beneficios a corto plazo con los beneficios a largo plazo. – coredump

0

Tal vez la implementación del compilador Lisp incluye un ejemplo del patrón de Intérprete.

No creo que deba decir que la "rueda", por ejemplo, es un antipatrón, aunque normalmente debería comprar ruedas confeccionadas en lugar de reinventarlas.

0

El intérprete es la idea detrás del generador del analizador JavaCC. Creo que funciona bien

El intérprete es un patrón de GoF mucho más respetable que Singleton. Ese es el que necesita ser votado fuera de la isla. Tal vez Memento también.

0

Una de las razones por las que se inventó XML fue para salvarnos de todos los intérpretes de EDI de escritura; pero al menos el alcance estaba bien definido, y todos lo hicimos aproximadamente igual (al menos suficientemente) de manera eficiente. Al menos estoy lo suficientemente engañado para pensar que fue lo correcto.

¿Parece que estás intentando iniciar una nueva leyenda urbana? ¿Estás congenitamente opuesto a los idiomas específicos del dominio?

+0

"¿Estás congenitamente opuesto a los idiomas específicos del dominio?" -- De ningún modo. De hecho, estoy usando un esquema integrado para mi aplicación de adaptador wiimote-to-XTest, con un conjunto limitado de primitivas en la API del archivo de configuración del usuario. No estoy seguro de qué hacer con el patrón de diseño de INTÉRPRETES. // Tal vez me han presentado para diseñar patrones de la manera incorrecta: como un conjunto de reglas estrictas (lo llamo "el modelo de camisa de fuerza de patrones de diseño"), mientras que de hecho son solo un conjunto de pautas e inspiración sueltas (que Yo llamo "el modelo muse de patrones de diseño"). –

14

Cualquier patrón de diseño es un antipatrón si se usa incorrectamente.

buenos usos de la Interpreter Pattern:

  • compilador de software
  • motor de evaluación de SQL
  • gráfica analizador de entrada calculadora
  • analizador XML

Estos son todos los programas que resuelven el problema de evaluar palabras en un idioma, whatever that language may be.

+1

"Motor de evaluación SQL" - Ermm ... ¿no? AFAICT, el patrón de INTÉRPRETE dice que se evalúa el árbol de abajo hacia arriba. Un planificador de consultas modestamente sofisticado hará transformaciones a consultas suficientemente complicadas que las aceleren, a veces dramáticamente. Ejecutar SQL con una evaluación de abajo hacia arriba no es el camino correcto a seguir. (Del mismo modo para los compiladores). Pero ... ¿el INTÉRPRETE está hablando de cualquier tipo de recorrido AST? Además, ¿no es lo opuesto/dual/ortogonal al Visitante? –

-1

Generalmente las fases de un compilador/intérprete se ve así:

  1. Sintaxis
  2. Parse árbol
  3. AST
  4. Compilar o interpretar

En Lisp, 1 y 2 se combinan en 3.

Theref También es un poco obvio que los programas complejos pueden tener un lenguaje personalizado incrustado en ellos que es "una implementación lenta, ad hoc, informalmente especificada, plagada de errores, de la mitad de Common Lisp".

Sin embargo, tendría que decir que escribir árboles AST a mano es desagradable y no es el final en todos los idiomas, sin importar cuántos Lispers afirmen que sea.

3

En algún momento u otro, un proyecto probablemente necesitará un sistema de configuración. al principio, todo lo que se necesita es algo simple, algo así como pares clave-valor para que el sistema pueda conectarse a la base de datos local, o algo así. Si esto es todo lo que se necesita, es común piratear un analizador simple para un dialecto de INI o CSV y seguir adelante. Pero a medida que el sistema crece y madura, se le da más importancia a la configuración. Esto es normal y saludable, la funcionalidad de refactorización y la responsabilidad de la capa correcta de abstracción. A partir de aquí, los desarrolladores o incluso los usuarios de (gasp) no tardarán en querer un lenguaje de configuración más expresivo. Antes de que nadie lo note, el sistema tiene un lenguaje completo integrado y en uso.

Este es el patrón básico de Greenspunning. Todo estaba bien diseñado hasta ese último momento, donde se introdujo un lenguaje ad-hoc en el ámbito del trabajo computacional real.

Cualquier sistema de un tamaño decente probablemente debe contener al menos la mitad de clisp.

Sabiendo que de antemano es un gran paso. Una forma muy conveniente de escribir sistemas grandes es elegir un lenguaje interpretativo fácil de hackear y escribir su sistema en él. Esto es exactamente lo que TCL está diseñado para hacer, pero en estos días es difícil encontrar a alguien detrás de un gran proyecto en ese idioma. Por otro lado, hay muchos otros idiomas que ahora ofrecen todos estos beneficios.

El beneficio de hacer las cosas de esta manera es el Active File Pattern. Las configuraciones simples están escritas de una manera que es compatible con un analizador de lenguaje que está disponible para el sistema. Dado que el idioma del archivo está siendo analizado, la lógica más compleja se puede incrustar fácilmente.

Un ejemplo de esto en la naturaleza es django's settings.py.Por alguna razón, django no es muy inteligente al adivinar dónde está instalado el proyecto django. Usando un conjunto de standard python en el archivo de configuración, esto se puede manejar en el caso general de una manera portátil, que se adaptará a casi todos los usuarios posibles. A pesar de eso, la mayoría del archivo settings.py se parece a los pares simples de clave = valor típicos de los archivos de configuración de estilo .ini.

La relación con el patrón de intérprete es que es probable que estos lenguajes maduros obtengan el patrón ,, incluso para algunos usos patológicos. Tan pronto como sepa que necesita analizar algo, proponga una muy buena razón para no usar un idioma existente para ello.

8

Tenga en cuenta que el 'patrón de intérprete' es un patrón de diseño específico en OOP.

No tiene nada que ver con 'Intérpretes' o sus usos en general.

2

El patrón del intérprete no implica escribir un lenguaje de scripting general completo. Si lo necesita, obviamente tendría más sentido usar un idioma bien conocido sobre el que las personas ya han escrito buenos libros (o lo mejor de todo, para permitir que el usuario elija el idioma).

patrón El intérprete es más acerca de la idea de la persistencia de un gráfico de objetos, pero la elección de un formato de persistencia que es legible y editable humana (como 2 + 3 que representa un objeto Addition con punteros a un par de Integer objetos). Incluso si esto nunca se expone a los clientes como un "idioma", aún ayuda a la depuración, soporte, piratería en el sitio, etc. Otros ejemplos comunes serían los lenguajes de consulta como HQL en [N] Hibernate: ningún lenguaje existente habría sido tan bueno para describir una consulta en ese nivel de abstracción.

Como han sugerido otros, XML se utiliza comúnmente como sintaxis básica para esto (especialmente cuando se concibe el gráfico persistente como un "archivo de configuración", y también para XAML de Microsoft), pero en realidad es una opción subóptima . JSON en UTF-8 (o similar) sería más limpio, más fácil de analizar, más legible y editable, y probablemente mejor para la mayoría de las aplicaciones. Pero hay algunas librerías analizadoras livianas que toman una descripción de sintaxis similar a BNF y luego pueden analizar texto en una estructura caminable tipo DOM, todo en tiempo de ejecución, por lo que cocinar un sintaxis sucinto muy específico no es un problema.

0

Usted obviamente no es un Lisp "fanboy", porque los niños y niñas que se ajustan a esa descripción generalmente se puede confiar en saber que Lisp es un lenguaje compilado. Lisp apareció en 1958. El manual de Lisp 1 fechado en 1961 ya describe la compilación.

La interpretación es útil; nos da semántica sin tener que escribir un compilador primero. Esta semántica proporciona un modelo de referencia para la semántica compilada: idealmente, los programas interpretados y compilados hacen lo mismo. Cuando descubrimos que no lo hacen, o lo resolvemos, o de alguna manera delineamos y justificamos la situación.

La interpretación se puede utilizar para arrancar un sistema Lisp compilado sin necesidad de una implementación de Lisp existente, sino utilizando otro lenguaje como C. La interpretación evita la necesidad de escribir un compilador Lisp en el lenguaje de arranque.

La implementación de CLISP de ANSI Common Lisp es un buen ejemplo de esto. Para compilar CLISP solo necesita un compilador de C. El compilador Lisp de CLISP está escrito en Lisp. Entonces, por supuesto, no tienes nada con que ejecutar ese compilador. La solución es interpretar el compilador utilizando un intérprete escrito en C.

Mientras se ejecuta interpretado, el compilador compila gran parte de la biblioteca Lisp.El resultado de esto es lo que CLISP llama una "imagen de memoria compilada a medias": una imagen que contiene rutinas compiladas, pero algunas rutinas interpretadas. (Creo que el compilador en sí es aún código interpretado).

Esta imagen medio compilada se utiliza para compilar el código restante, lo que da como resultado la imagen completamente compilada.

Sin el intérprete, el compilador de CLISP solo se pudo arrancar al insistir en que se instale primero otra implementación de Lisp. (La forma en que necesita un compilador de C para boostrap GCC). O bien, el compilador de CLISP debería escribirse en C, de modo que el compilador se compila con el compilador de C existente y luego se aplica al código Lisp para compilarlo antes de que pueda ejecutarse.

Nadie en su sano juicio desea escribir un compilador Lisp en C, y requerir una implementación de Lisp para construir una implementación de Lisp es una gran desventaja en un mundo en el que Lisp no es omnipresente. Lo que sucedería bajo el modelo de boostrapping Lisp-compiler-in-C es que el compilador Lisp escrito en C sería completamente minimalista y posiblemente incompleto, que emite código de baja calidad, solo lo suficientemente bueno para iniciar el boostrapping, y un "real" el compilador aún estaría escrito en Lisp.

Cuestiones relacionadas