Re: metronome-mark-alignment

[Thomas Morley]

Am Mo., 13. Jan. 2020 um 07:14 Uhr schrieb Daniel Rosen <address@hidden>:
>
> > -----Original Message-----
> > From: Thomas Morley [mailto:address@hidden]
> > Sent: Sunday, January 12, 2020 6:04 PM
> > To: Daniel Rosen <address@hidden>
> > Cc: David Nalesnik <address@hidden>; lilypond-user Mailing List
> > (address@hidden) <address@hidden>
> > Subject: Re: metronome-mark-alignment
> >
> > Though, I've already heard about difficulties about using scheme to write
> > own extension pretty often.
> > Just like you say:
> >
> > Am So., 12. Jan. 2020 um 22:19 Uhr schrieb Daniel Rosen
> > <address@hidden>:
> > > I want to express how grateful I am to this list for being so helpful
> > > with this issue, since I have zero knowledge about how to use Scheme.
> > > (I've tried to tackle the Extending manual on multiple occasions, but
> > > I find it extremely difficult to understand, probably because I have
> > > no programming experience.)
> >
> > I have the suspicion it's not, because guile is difficult, at least so far 
> > as the
> > scheme-tutorial reaches out, but because it's difficult to find a way to 
> > modify
> > LilyPond's default with scheme. In the sense of:
> > What am I supposed to do with my new basic guile-knowledge?
> > Note that most used tools in David's and my coding are _not_ native guile-
> > procedures, but are defined in the LilyPond-source.
> > Therefore I think the problem is more poor documentation of those lily-
> > defined tools and/or the lack of commented code-examples using them.
> >
> > Could you confirm or is it something else preventing you from starting to
> > code on your own?
>
> The most important thing preventing me from starting to code on my own is 
> simple: I don't have to. LilyPond natively supports so many different 
> notational constructs that I run into problems relatively infrequently. And 
> in the cases when I do, between the manuals, the LSR, and this list 
> (primarily the archives, and occasionally responses to my own submissions), 
> I've been able to simply copy-paste my way out of practically any jam I've 
> found myself in for as long as I've used LilyPond (which must be almost ten 
> years).
>

Well, does this mean LilyPond is too good, the Documentation
overwhelming nice and the mailing-list far too active and helpful?
LOL

> As far as the Extending manual goes, though... I could be wrong, but it seems 
> to assume a basic working knowledge of how computer programs and programming 
> languages work that I simply don't have. Going through it, I think to myself 
> that I would need to have one-on-one tutoring sessions with someone in order 
> to really understand it. Take 1.2.1 
> (http://lilypond.org/doc/v2.19/Documentation/extending/lilypond-scheme-syntax)
>  as an example. This paragraph
>
> > 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. I like to think I understand the basic idea, but I 
> can never be sure because I'm unfamiliar with so much of the language: 
> "lexer," "Scheme reader," "SCM_TOKEN," "parser." And the rest of the page is 
> no better. So while I'm sure that you're right about the manual's 
> ineffectiveness in helping readers transfer their knowledge of Guile into 
> practice within LilyPond, in my case the issue lies even deeper than 
> that---I'm never sure whether I'm really understanding what the manual is 
> trying to tell me.
>
> Of course, it may be that the manual isn't meant to be aimed at a complete 
> novice like myself; but if it is, then it definitely needs an overhaul.
>
> DR

Hi,

David answered already, let me add my 2 cents.

Part of the problem is the need to adress both, novices _and_
experienced programmers...

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."



Cheers,
  Harm