Re: metronome-mark-alignment

[David Kastrup]

Thomas Morley <address@hidden> writes:

> Am Mo., 13. Jan. 2020 um 07:14 Uhr schrieb Daniel Rosen <address@hidden>:
>>
>> > The hash mark # method of embedding Scheme is a natural fit for this 
>> > system.
>> > Once the lexer sees a hash mark, it calls the Scheme reader to read one 
>> > full Scheme
>> > expression (this can be an identifier, an expression enclosed in
>> > parentheses, or several
>> > other things). After the Scheme expression is read, it is stored
>> > away as the value for an
>> > SCM_TOKEN in the grammar. Once the parser knows how to make use of this 
>> > token, it
>> > calls Guile for evaluating the Scheme expression. Since the parser
>> > usually requires a bit
>> > of lookahead from the lexer to make its parsing decisions, this separation 
>> > of reading
>> > and evaluation between lexer and parser is exactly what is needed to keep 
>> > the
>> > execution of LilyPond and Scheme expressions in sync. For this reason, you 
>> > should use
>> > the hash mark # for calling Scheme whenever this is feasible.
>>
>> mostly goes over my head.
>
> Would it have been more helpful, reading something at the lines of
> (mostly a reorder of sentences):
>
> "You should use the hash mark # for calling Scheme whenever this is feasible.
>
> Here some details, skip them until you think you need them:
>
> The hash mark # method of embedding Scheme is a natural fit for this
> system. Once the lexer sees a hash mark, it calls the Scheme reader to
> read one full Scheme expression (this can be an identifier, an
> expression enclosed in parentheses, or several other things). After
> the Scheme expression is read, it is stored away as the value for an
> SCM_TOKEN in the grammar. Once the parser knows how to make use of
> this token, it calls Guile for evaluating the Scheme expression. Since
> the parser usually requires a bit of lookahead from the lexer to make
> its parsing decisions, this separation of reading and evaluation
> between lexer and parser is exactly what is needed to keep the
> execution of LilyPond and Scheme expressions in sync."

Ok, let me try again.

# and $ differ in several respects.  # inserts Scheme constructs in
places where LilyPond can decide how they fit into its syntax without
looking at their value first.  In that case, evaluation of those Scheme
expressions is done at the time the expression is being actually used
which tends to be what one expects.  In contrast, $ can be used in
places where the value of the expression will have an impact on just how
LilyPond will put them into context.  For example, a $ expression
evaluating to a duration may be combined with a preceding pitch to form
a note, while having it evaluate to another pitch in the same place will
form a separate note.

This syntactic flexibility may lead to the expression getting evaluated
at an unexpectedly early point of time, namely when LilyPond needs to
know its type in order to decide that it does not actually combine with
the preceding expression.

------

So no talk about lexer and parser and lookahead and tokens.

-- 
David Kastrup