[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < Percussion notes ] | [ 上へ : Notation manual tables ] | [ alist > ] |
A.15 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 | ||
callback | ||
closure | ||
glyph | ||
grob | ||
immutable | ||
interface | ||
lexer | ||
mutable | ||
output-def | ||
parser | ||
parser variable | ||
prob | ||
simple closure | ||
smob | ||
stencil |
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < Technical glossary ] | [ 上へ : Technical glossary ] | [ callback > ] |
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.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < alist ] | [ 上へ : Technical glossary ] | [ closure > ] |
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.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < callback ] | [ 上へ : Technical glossary ] | [ glyph > ] |
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.
A simple closure is a closure whose expression has no free
variables and hence no free variable bindings.
A simple closure is represented in LilyPond by a smob containing
the expression and a method to apply the expression to a passed
list of arguments.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < closure ] | [ 上へ : Technical glossary ] | [ grob > ] |
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.
参照
Notation Reference:
フォント,
特殊文字.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < glyph ] | [ 上へ : Technical glossary ] | [ immutable > ] |
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.
参照
Learning Manual:
Objects and interfaces
,
Naming conventions of objects and properties
,
Properties of layout objects
.
Internals Reference:
grob-interface
,
All layout objects
.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < grob ] | [ 上へ : Technical glossary ] | [ interface > ] |
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
.
参照
Notation Reference:
mutable.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < immutable ] | [ 上へ : Technical glossary ] | [ lexer > ] |
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.
参照
Learning Manual:
Objects and interfaces
,
Naming conventions of objects and properties
,
Properties found in interfaces
.
Notation Reference:
レイアウト インターフェイス.
Internals Reference:
Graphical Object Interfaces
.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < interface ] | [ 上へ : Technical glossary ] | [ mutable > ] |
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.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < lexer ] | [ 上へ : Technical glossary ] | [ output-def > ] |
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.
参照
Notation Reference:
immutable.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < mutable ] | [ 上へ : Technical glossary ] | [ parser > ] |
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.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < output-def ] | [ 上へ : Technical glossary ] | [ parser variable > ] |
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 LilyPond 文法. 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.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < parser ] | [ 上へ : Technical glossary ] | [ prob > ] |
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
parseStringResult
partCombineListener
pitchnames
toplevel-bookparts
toplevel-scores
showLastLength
showFirstLength
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < parser variable ] | [ 上へ : Technical glossary ] | [ simple closure > ] |
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.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < prob ] | [ 上へ : Technical glossary ] | [ smob > ] |
simple closure
See closure.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < simple closure ] | [ 上へ : Technical glossary ] | [ stencil > ] |
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’.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < smob ] | [ 上へ : Technical glossary ] | [ All context properties > ] |
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.
参照
Internals Reference:
grob-interface
.
[ << Notation manual tables ] | [トップ][目次][インデックス][ ? ] | [ カンニング ペーパー >> ] | ||
[ < smob ] | [ 上へ : Technical glossary ] | [ All context properties > ] |
他の言語: English, deutsch, español, italiano
About automatic language selection.