Re: metronome-mark-alignment

[Thomas Morley]

Am Mi., 15. Jan. 2020 um 01:23 Uhr schrieb David Kastrup <address@hidden>:
>
> 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

I just stumbled across:

~$ lilydevel scheme-sandbox
GNU LilyPond 2.19.83
Processing 
`/home/hermann/lilydevel/usr/share/lilypond/current/ly/scheme-sandbox.ly'
Parsing...
guile> (display-lily-music #{ $(ly:parser-include-string "\\tweak
color $red") b4 #})
\tweak color #'(1.0 0.0 0.0) b4


If you do the same with #red, below returns:
\tweak color #"red" b4

Not sure what we may want here...

Cheers,
  Harm