Z:gnu-www-ja-rms-lisp--184634-At that point, people began to/es

Llegado este punto, la gente se empezó a preguntar cómo podría conseguir algo así en una plataforma que no poseyera una implementación de Lisp completa. Multics MacLisp tenía tanto un compilador como un intérprete, era un sistema Lisp con todas las de la ley, pero la gente quería implementar algo similar en otros sistemas para los cuales todavía no había programado un compilador de Lisp. Bien, si no tenía el compilador de Lisp no podía escribir todo el editor en Lisp: resultaría demasiado lento, especialmente al refrescar la pantalla, si tenía que ejecutarse en Lisp interpretado. Así que desarrollamos una técnica híbrida. La idea era escribir conjuntamente un intérprete de Lisp y los fragmentos de nivel más bajo del editor, de forma que algunos fragmentos del editor fueran mecanismos incorporados en el intérprete de Lisp. Estos fragmentos serían todas aquellas partes que consideráramos que teníamos que optimizar. Ya habíamos utilizado esta técnica en el Emacs original, cuando reescribimos en lenguaje máquina algunas funciones de nivel relativamente alto, transformándolas en primitivas TECO. Por ejemplo, había una primitiva TECO para rellenar un párrafo (en realidad, para hacer casi todo el trabajo necesario para rellenar un párrafo, porque algunas de las tareas que menos tiempo consumían eran realizadas en un nivel superior por un programa TECO ). Se podría haber hecho todo el trabajo con un programa TECO, pero habría resultado demasiado lento, por eso lo optimizamos escribiendo parte de él en lenguaje máquina. Esa misma idea es la que usamos aquí (en la técnica híbrida): escribimos la mayoría del editor en Lisp, pero escribimos en un nivel inferior algunas partes que tenían que ejecutarse particularmente rápido.