Re: metronome-mark-alignment

[Thomas Morley]

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?

Cheers,
  Harm