Re: metronome-mark-alignment

[David Kastrup]

Thomas Morley <address@hidden> writes:

> Am Di., 14. Jan. 2020 um 23:39 Uhr schrieb David Kastrup <address@hidden>:
>>
>> 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
>
> Hi David,
>
> I like this, though I like current explanations in Extending as well.
> Both give detailed infos about the topic, though, imho, for a novice
> it's kind of TMI.
>
> Let me go back some time, I started my first coding attempts somewhere
> at 2.14. or such.
> Extending Manual for 2.14 reads
> "
> 1.2.1 LilyPond Scheme syntax
>
> The Guile interpreter is part of LilyPond, which means that Scheme can
> be included in LilyPond input files. The hash mark # is used to tell
> the LilyPond parser that the next value is a Scheme value.
>
> Once the parser sees a hash mark, input is passed to the Guile
> interpreter to evaluate the Scheme expression. The interpreter
> continues to process input until the end of a Scheme expression is
> seen.
> [...]
> "
> Is this wrong? Well, incomplete, at least nowadays... but not that bad
> for a first approximation.
>
> What I'm trying to say: I'd prefer some simplified/summarized info at
> first sight with the option to read up more, if wished and/or needed.
>
> WDYT?

We need to put out the difference between # and $ even for beginners.
Basically # can only be used for stuff where you can figure out the
meaning in context without even looking at the Scheme expression
involved.  Which has the advantage that the Scheme expression does not
get looked at earlier than expected.  While $ (like \ ) can change the
interpretation of stuff around it depending on what it evaluates to but
that means that LilyPond may try evaluating it earlier than expected.

The typical problem case we have is

blabla = something
\blabla

when LilyPond is not sure that something is a complete expression before
looking at what is following it.

-- 
David Kastrup