+@node Glosario técnico
+@appendixsec Glosario técnico
+@translationof Technical glossary
+
+Glosario de los términos técnicos y conceptos que se utilizan
+internamente en LilyPond. Estos términos pueden aparecer en los
+manuales, en las listas de distribución de correo o en el código
+fuente.
+
+@menu
+* alist (lista-A)::
+* callback::
+* closure (cerradura)::
+* glifo::
+* grob (objeto gráfico)::
+* inmutable::
+* interfaz::
+* lexer (analizador léxico)::
+* mutable::
+* output-def (definición de salida)::
+* parser (analizador sintáctico)::
+* variable del analizador sintáctico::
+* prob (objeto de propiedades)::
+* cerradura simple::
+* smob (objeto de Scheme)::
+* stencil (sello)::
+@end menu
+
+
+@node alist (lista-A)
+@unnumberedsubsec alist (lista-A)
+@translationof alist
+
+@cindex lista-A
+@cindex lista de asociación
+@cindex alist
+
+Una lista asociativa o abreviadamente una @strong{lista-A} (alist en
+inglés) es una pareja de Scheme que asocia un valor con una clave:
+@w{@code{(clave . valor)}}. Por ejemplo, en @file{scm/lily.scm}, la
+lista-A @w{@qq{type-p-name-alist}} asocia ciertos predicadps de tipo
+(p.ej.@tie{}@code{ly:music?}) con nombres (p.ej.@tie{}@qq{music}) de
+forma que se pueda informar de los fallos de comprobación de tipo con
+un mensaje de consola que incluye el nombre del predicado de tipo
+esperado.
+
+
+@node callback
+@unnumberedsubsec callback
+@translationof callback
+
+@cindex callback
+
+Una @strong{callback} es una rutina, función o método cuya referencia
+se pasa como argumento en una llamada a otra rutina, permitiendo así
+que la runtina llamada invoque a aquélla. La técnica permite que una
+capa de software de nivel más bajo llame a una función definida en una
+capa de nivel más alto. Las funciones de callback se usan ampliamente
+en LilyPond para permitir al código de Scheme del nivel de usuario
+definir cuántas acciones de bajo nivel se llevan a cabo.
+
+
+@node closure (cerradura)
+@unnumberedsubsec closure (cerradura)
+@translationof closure
+
+@cindex cerradura
+@cindex cerradura simple
+
+En Scheme, se crea una @strong{cerradura} cuando una función, por lo
+general una expresión lambda, se pasa como variable. La cerradura
+contiene el codigo de la función y referencias a las ligaduras léxicas
+de las variables libres de la función (es decir, las variables que se
+usan en la expresión pero se definen fuera de ella). Cuando más tarde
+se aplica esta función a diferentes argumentos, las ligaduras de
+variables libres que se capturaron dentro de la cerradura se utilizan
+para obtener los valores de las variables libres que se usarán en el
+cálculo. Una propiedad útil de las cerraduras es la retención de los
+valores internos de las variables de una invocación a otra,
+permitiendo así que se pueda mantener un estado.
+
+Una @strong{cerradura simple} es una cerradura cuya expresión no tiene
+variables libres y por ello no tiene ligaduras de variables libres.
+
+Una cerradura simple se representa en LilyPond mediante un @q{smob}
+que contiene la expresión y un método para aplicar la expresión a la
+lista de argumentos que se le pasa.
+
+
+@node glifo
+@unnumberedsubsec glifo
+@translationof glyph
+
+@cindex glifo
+@cindex fuente tipográfica
+@cindex tipografía
+
+Un @strong{glifo} es una representación gráfica particular de un
+carácter tipográfico, o una combinación de dos caracteres que forman
+una ligadura. Un conjunto de glifos con un estilo y forma uniformes
+forman una fuente tipográfica, y un conjunto de fuentes tipográficas
+que abarcan varios estilos forman un tipo.
+
+@seealso
+Referencia de la notación:
+@ref{Tipografías},
+@ref{Caracteres especiales}.
+
+
+@node grob (objeto gráfico)
+@unnumberedsubsec grob (objeto gráfico)
+@translationof grob
+
+@cindex grob
+@cindex objetos de presentación
+@cindex objetos gráficos
+
+Los objetos de LilyPond que representan elementos de la notación en la
+salida impresa tales como la cabeza y la plica de las notas, ligaduras
+de unión y de expresión, digitaciones, claves, et. se denominan
+@q{objetos de presentación}, a menudo conocidos como @q{OBjetos
+GRáficos}, o abreviadamente @strong{grobs}. Se representan mediante
+instancias de la clase @code{Grob}.
+
+@seealso
+Manual de aprendizaje:
+@rlearning{Objetos e interfaces},
+@rlearning{Convenciones de nombres de objetos y propiedades},
+@rlearning{Propiedades de los objetos de presentación}.
+
+Referencia de funcionamiento interno:
+@rinternals{grob-interface},
+@rinternals{All layout objects}.
+
+
+@node inmutable
+@unnumberedsubsec inmutable
+@translationof immutable
+
+@cindex objetos inmutables
+@cindex propiedades inmutables
+@cindex propiedades compartidas
+
+Un objeto @strong{inmutable} es aquél cuyo estado no se puede
+modificar después de su creación, en contraste con los objetos
+mutables, que se pueden modificar después de su creación.
+
+En LilyPond, las propiedades inmutables o compartidas definen el
+estilo y comportamiento predeterminados de los grobs. Se comparten
+por parte de muchos objetos. En aparente contradicción con su nombre,
+se pueden cambiar utilizando @code{\override} y @code{\revert}.
+
+@seealso
+Referencia de la notación:
+@ref{mutable}.
+
+
+@node interfaz
+@unnumberedsubsec interfaz
+@translationof interface
+
+@cindex interfaz
+@cindex interfaz de grob
+@cindex interfaces de objetos gráficos
+
+Las acciones y propiedades comunes a un conjunto de grobs se agrupan
+en un objeto denominado @code{interfaz de grob (grob-inerface)}, o
+abreviadamente @q{interfaz}.
+
+@seealso
+Manual de aprendizaje:
+@rlearning{Objetos e interfaces},
+@rlearning{Convenciones de nombres de objetos y propiedades},
+@rlearning{Propiedades de los interfaces}.
+
+Referencia de la notación:
+@ref{Interfaces de la presentación}.
+
+Referencia de funcionamiento interno:
+@rinternals{Graphical Object Interfaces}.
+
+
+@node lexer (analizador léxico)
+@unnumberedsubsec lexer (analizador léxico)
+@translationof lexer
+
+@cindex lexer
+@cindex analizador léxico
+@cindex Flex
+
+Un @strong{lexer} o analizador léxico es un programa que convierte una
+secuencia de caracteres en una secuencia de elementos o tokens, en un
+proceso que se llama análisis léxico. El analizador léxico de
+LilyPond convierte el flujo obtenido a partir de un archivo de entrada
+@file{.ly} en un flujo descompuesto en tokens más apto para la
+siguiente fase del procesado: el análisis sintáctico, véase
+@ref{parser (analizador sintáctico)}. El analizador léxico de
+LilyPond lexer está construido con la herramienta Flex a partir del
+archivo de lexer @file{lily/lexer.ll} que contiene las reglas léxicas.
+Este archivo es parte del código fuente y no se incluye dentro de la
+instalación binaria de LilyPond.
+
+
+@node mutable
+@unnumberedsubsec mutable
+@translationof mutable
+
+@cindex objetos mutables
+@cindex propiedades mutables
+
+Un objeto @strong{mutable} es aquél cuyo estado se puede modificar
+después de su creación, en contraste con un objeto inmutable, cuyo
+estado se fija en el momento de la creación.
+
+En LilyPond, las propiedades mutables contienen valores específicos de
+un grob. Por lo general, las listas de otros objetos o los resultados
+de los cálculos se almacenan en propiedades mutables.
+
+@seealso
+Referencia de la notación:
+@ref{inmutable}.
+
+
+@node output-def (definición de salida)
+@unnumberedsubsec output-def (definición de salida)
+@translationof output-def
+
+@cindex output-def
+@cindex definición de salida
+
+Una instancia de la clase @code{Output-def} contiene los métodos y
+estructuras de datos asociados con un bloque de salida. Se crean
+instancias parra los bloques midi, layout y paper.
+
+
+@node parser (analizador sintáctico)
+@unnumberedsubsec parser (analizador sintáctico)
+@translationof parser
+
+@cindex parser
+@cindex analizador sintáctico
+@cindex Bison
+@cindex gramática de LilyPond
+@cindex BNF
+
+Un @strong{parser} o analizador sintáctico analiza la secuencia de
+tokens o elementos léxicos producida por un analizador léxico para
+determinar su estructura gramatical, agrupando los elementos léxicos
+en conjuntos mayores según las reglas de la gramática. Si la
+secuencia de elementos léxicos es válida, el producto final es un
+árbol de tokens cuya raíz es el símbolo inicial de la gramática. Si
+no se puede conseguir esto, el archivo es inválido y se produce un
+mensaje de error adecuado. Las agrupaciones sintácticas y las reglas
+para construir estas agrupaciones a partir de sus elementos
+constituyentes para la sintaxis de LilyPond están definidas en
+@file{lily/parser.yy} y se muestran en la forma normal de Backus (BNF)
+dentro de @rcontrib{LilyPond grammar}. Este archivo se usa para
+construir el analizador sintáctico durante la compilación del programa
+por parte del generador de analizadores sintácticos, Bison. Es parte
+del código fuente y no se incluye dentro de la instalación binaria de
+LilyPond.
+
+
+@node variable del analizador sintáctico
+@unnumberedsubsec variable del analizador sintáctico
+@translationof parser variable
+
+@cindex variable del analizador sintáctico
+@cindex variable de Scheme
+@cindex variable global
+@cindex afterGraceFraction
+@cindex musicQuotes
+@cindex modo
+@cindex output-count
+@cindex output-suffix
+@cindex partCombineListener
+@cindex pitchnames
+@cindex toplevel-bookparts
+@cindex toplevel-scores
+@cindex showLastLength
+@cindex showFirstLength
+
+Son variables definidas directamente dentro de Scheme. Su uso directo
+por parte de los usuarios está fuertemente desaconsejado, porque su
+semántica de ámbito puede ser confusa.
+
+Cuando el valor de una de estas variables se modifica dentro de un
+archivo @file{.ly}, el cambio es global, y a no ser que se revierta
+explícitamente, el nuevo valor persistirá hasta el final del archivo,
+afectando a todos los bloques @code{\score} así como a los archivos
+externos añadidos con la instrucción @code{\include}. Esto puede
+conducir a consecuencias imprevistas y en proyectos de composición
+tipográfica complejos puede ser difícil de rastrear.
+
+LilyPond utiliza las siguientes variables del analizador sintáctico:
+
+@itemize
+@item afterGraceFraction
+@item musicQuotes
+@item mode
+@item output-count
+@item output-suffix
+@item partCombineListener
+@item pitchnames
+@item toplevel-bookparts
+@item toplevel-scores
+@item showLastLength
+@item showFirstLength
+@end itemize
+
+
+@node prob (objeto de propiedades)
+@unnumberedsubsec prob (objeto de propiedades)
+@translationof prob
+
+@cindex objeto de propiedades
+@cindex prob
+
+Los OBjetos de PRopiedades, o abreviadamente @strong{probs}, son
+instancias de la clase @code{Prob}, que es una sencilla clase básica
+que tiene listas-A de propiedades mutables e inmutables y los métodos
+para manipularlas. Las clases @code{Music} y @code{Stream_event}
+derivan de @code{Prob}. También se crean instancias de la clase
+@code{Prob} para almacenar el contenido formateado de los grobs del
+sistema y los bloques de títulos durante el proceso de disposición de
+la página.
+
+
+@node cerradura simple
+@unnumberedsubsec cerradura simple
+@translationof simple closure
+
+Véase @ref{closure (cerradura)}.
+
+
+@node smob (objeto de Scheme)
+@unnumberedsubsec smob (objeto de Scheme)
+@translationof smob
+
+@cindex smob
+@cindex objeto de Scheme
+
+Los @strong{Smobs}, u OBjetos de ScheMe, forman parte del mecanismo
+utilizado por Guile para exportar objetos de C y de C++ al código de
+Scheme. En LilyPond, se crean smobs a partir de objetos de C++ por
+medio de macros. Hay dos tipos de objetos smob: los smobs simples,
+orientados a objetos inmutables simples como números, y los smobs
+complejos, usados para objetos con identidades. Si tiene acceso a las
+fuentes de LilyPond sources, encontrará más información en
+@file{lily/includes/smob.hh}.
+
+
+@node stencil (sello)
+@unnumberedsubsec stencil (sello)
+@translationof stenci
+
+@cindex stencil
+@cindex sello
+
+Las instancias de la clase @strong{stencil} contienen la información
+necesaria para imprimir un objeto tipográfico. Es un smob simple que
+contiene una caja de confinamiento, que a su vez define las
+dimensiones vertical y horizontal del objeto, y una expresión de
+Scheme que imprime el objeto cuendo se evalúa. Los stencils o sellos
+se pueden combinar para formar sellos más complejos definidos por un
+árbol de expresiones de Scheme formado a partir de las expresiones de
+Scheme de los sellos que lo componen.
+
+La propiedad @code{stencil}, que conecta a un grob con su sello, se
+define dentro del interfaz @code{grob-interface}.
+
+@seealso
+Referencia de funcionamiento interno:
+@rinternals{grob-interface}.
+
+