Am Di., 14. Jan. 2020 um 23:39 Uhr schrieb David Kastrup <d...@gnu.org>: > > Thomas Morley <thomasmorle...@gmail.com> writes: > > > Am Mo., 13. Jan. 2020 um 07:14 Uhr schrieb Daniel Rosen > > <drose...@gmail.com>: > >> > >> > 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
