A.16 Technical glossary

A glossary of the technical terms and concepts used internally in LilyPond. These terms may appear in the manuals, on mailing lists or in the source code.

alist

An association list or alist for short is a Scheme pair which associates a value with a key: (key . value). For example, in ‘scm/lily.scm’, the alist “type-p-name-alist” associates certain type predicates (e.g., ly:music?) with names (e.g., “music”) so that type-check failures can be reported with a console message that includes the name of the expected type predicate.

callback

A callback is a routine, function or method whose reference is passed as an argument in a call to another routine, so allowing the called routine to invoke it. The technique enables a lower- level software layer to call a function defined in a higher layer. Callbacks are used extensively in LilyPond to permit user-level Scheme code to define how many low-level actions are performed.

closure

In Scheme, a closure is created when a function, usually a lambda expression, is passed as a variable. The closure contains the function’s code plus references to the lexical bindings of the function’s free variables (i.e., those variables used in the expression but defined outside it). When this function is applied to different arguments later, the free variable bindings that were captured in the closure are used to obtain the values of the free variables to be used in the calculation. One useful property of closures is the retention of internal variable values between invocations, so permitting state to be maintained.

glyph

A glyph is a particular graphical representation of a typographic character, or a combination of two characters formating a ligature. A set of glyphs with a single style and shape comprise a font, and a set of fonts covering several styles and sizes comprise a typeface.

See also

Notation Reference: Fonts, Special characters.

grob

LilyPond objects which represent items of notation in the printed output such as note heads, stems, slurs, ties, fingering, clefs, etc are called ‘Layout objects’, often known as ‘GRaphical OBjects’, or grobs for short. They are represented by instances of the Grob class.

See also

Learning Manual: (learning)Objects and interfaces section ‘Objects and interfaces’ in Learning Manual, (learning)Naming conventions of objects and properties section ‘Naming conventions of objects and properties’ in Learning Manual, (learning)Properties of layout objects section ‘Properties of layout objects’ in Learning Manual.

Internals Reference: (internals)grob-interface section ‘grob-interface’ in Internals Reference, (internals)All layout objects section ‘All layout objects’ in Internals Reference.

immutable

An immutable object is one whose state cannot be modified after creation, in contrast to a mutable object, which can be modified after creation.

In LilyPond, immutable or shared properties define the default style and behavior of grobs. They are shared between many objects. In apparent contradiction to the name, they can be changed using \override and \revert.

See also

Notation Reference: mutable.

interface

Actions and properties which are common to a number of grobs are grouped together in an object called a grob-interface, or just ‘interface’ for short.

See also

Learning Manual: (learning)Objects and interfaces section ‘Objects and interfaces’ in Learning Manual, (learning)Naming conventions of objects and properties section ‘Naming conventions of objects and properties’ in Learning Manual, (learning)Properties found in interfaces section ‘Properties found in interfaces’ in Learning Manual.

Notation Reference: Layout interfaces.

Internals Reference: (internals)Graphical Object Interfaces section ‘Graphical Object Interfaces’ in Internals Reference.

lexer

A lexer is a program which converts a sequence of characters into a sequence of tokens, a process called lexical analysis. The LilyPond lexer converts the stream obtained from an input ‘.ly’ file into a tokenized stream more suited to the next stage of processing - parsing, for which see parser. The LilyPond lexer is built with Flex from the lexer file ‘lily/lexer.ll’ which contains the lexical rules. This file is part of the source code and is not included in the LilyPond binary installation.

mutable

A mutable object is one whose state can be modified after creation, in contrast to an immutable object, whose state is fixed at the time of creation.

In LilyPond, mutable properties contain values that are specific to one grob. Typically, lists of other objects or results from computations are stored in mutable properties.

See also

Notation Reference: immutable.

output-def

An instance of the Output-def class contains the methods and data structures associated with an output block. Instances are created for midi, layout and paper blocks.

parser

A parser analyzes the sequence of tokens produced by a lexer to determine its grammatical structure, grouping the tokens progressively into larger groupings according to the rules of the grammar. If the sequence of tokens is valid the end product is a tree of tokens whose root is the grammar’s start symbol. If this cannot be achieved the file is invalid and an appropriate error message is produced. The syntactic groupings and the rules for constructing the groupings from their parts for the LilyPond syntax are defined in ‘lily/parser.yy’ and shown in Backus Normal Form (BNF) in (contributor)LilyPond grammar section ‘LilyPond grammar’ in Contributor’s Guide. This file is used to build the parser during the program build by the parser generator, Bison. It is part of the source code and is not included in the LilyPond binary installation.

parser variable

These are variables defined directly in Scheme. Their direct use by users is strongly discouraged, because their scoping semantics can be confusing.

When the value of such a variable is changed in a ‘.ly’ file, the change is global, and unless explicitly reverted, the new value will persist to the end of the file, affecting subsequent \score blocks as well as external files added with the \include command. This can lead to unintended consequences and in complex typesetting projects the consequent errors can be difficult to track down.

LilyPond uses the following parser variables:

• afterGraceFraction
• musicQuotes
• mode
• output-count
• output-suffix
• partCombineListener
• pitchnames
• toplevel-bookparts
• toplevel-scores
• showLastLength
• showFirstLength

prob

PRoperty OBjects, or probs for short, are instances of the Prob class, a simple base class for objects which have mutable and immutable property alists and the methods to manipulate them. The Music and Stream_event classes derive from Prob. Instances of the Prob class are also created to hold the formatted content of system grobs and titling blocks during page layout.

smob

Smobs, or ScheMe OBjects, are part of the mechanism used by Guile to export C and C++ objects to Scheme code. In LilyPond, smobs are created from C++ objects through macros. There are two types of smob objects: simple smobs, intended for simple immutable objects like numbers, and complex smobs, used for objects with identities. If you have access to the LilyPond sources, more information can be found in ‘lily/includes/smob.hh’.

stencil

An instance of the stencil class holds the information required to print a typographical object. It is a simple smob containing a confining box, which defines the vertical and horizontal extents of the object, and a Scheme expression which will print the object when evaluated. Stencils may be combined to form more complex stencils defined by a tree of Scheme expressions formed from the Scheme expressions of the component stencils.

The stencil property, which connects a grob to its stencil, is defined in the grob-interface interface.

See also

Internals Reference: (internals)grob-interface section ‘grob-interface’ in Internals Reference.

This document was generated by gub on July 13, 2020 using texi2html 1.82.

Jiné jazyky: català, deutsch, español, français, italiano, 日本語.
O automatickém výběru řeči.