Re: [PATCH] Add scheme engraver for StaffTab notation

[David Kastrup]

Werner LEMBERG <address@hidden> writes:

>>>   #(for-each
>>>     (lambda (elem)
>>>       (let* ((sym (car elem))
>>>              (chord (cdr elem)))
>>>         (ly:parser-include-string
>>>            parser
>>>            (string-append "\\makeDefaultStringTuning " sym "-tuning"
>>>                           " \\stringTuning <" chord ">"))))
>>>
>>>       '(("guitar" . "e, a, d b g e'")
>>>         ("guitar-seven-string" . "b,, e, a, d b g e'")
>>>         ("guitar-drop-d" . "d, a, d g b e'")
>>>         ("guitar-drop-c-tuning" . "c, g, c f a d'")
>>>          ...
>>>         )
>>>    )
>> 
>> Disagree.  The current solution has a constant visual pattern (just
>> that it does not use whitespace for that).  It's not significantly
>> less readable on a pure visual basis (one might want to block-align
>> the tuning names).  However, your version is utterly
>> incomprehensible on the basis of understanding what it does while
>> the original version has each line stand for itself, with a readily
>> readable _meaning_ of the line.
>
> It's not clear to me how an alist of tuning names and the associated
> string tunings is `utterly incomprehensible'...  Oh well.

So what is the purpose of having _strings_ here?  What does the . mean?
What do the parens mean?

>> All that ly:parser-include-string is actually on a level of code
>> ugliness even below using primitive-eval because it pieces together
>> stuff that is not even at a syntactical level.
>
> Yes, but exactly this is the power of `ly:parser-include-string'!

To hide from the editor and reader what one is doing?  So that you don't
get syntax highlighting and become unable to convert notenames or
absolute/relative?  Not everything that is possible to do is a good
idea.

> It is a nice utility to use Scheme's iteration stuff (i.e., `for-each'
> and friends) while not too deeply diving into Scheme.

I doubt that you even realize what you are doing here.  Let's put some
problems in:

#(for-each
  (lambda (elem)
    (let* ((sym (car elem))
           (chord (cdr elem)))
      (ly:parser-include-string
         parser
         (string-append "\\makeDefaultStringTuning " sym "-tuning"
                        " \\stringTuning <" chord ">"))))

    '(("guitar" . "e, a, d b g e'")
      ("guitar-seven-string" . "b,, e, a, d b g e'")
      ("guitar-drop-d" . "<d, a, d g b e'")
      ("guitar-drop-c-tuning" . "c, g, c f a d'>")))

Now what will the results be?  One error already introduced by yourself
is that guitar-drop-c-tuning will be undefined since instead you are
defining guitar-drop-c-tuning-tuning.  Which stresses my point about it
being a bad idea to use different words in definition and use.

The next thing to note is that the error messages are entirely
incomprehensible and that the lines are obviously processed in _reverse_
order (since a later ly:parser-include-string pushes another string to
the _top_ of the include stack where it is processed earlier than
strings lower in the stack).

lilypond /tmp/gork.ly
GNU LilyPond 2.19.16
Processing `/tmp/gork.ly'
Parsing...
<included string>:1:83: error: syntax error, unexpected >>
\makeDefaultStringTuning guitar-drop-c-tuning-tuning \stringTuning <c, g, c f a 
d'
                                                                                
  >>
<included string>:1:77: error: syntax error, unexpected >
\makeDefaultStringTuning guitar-drop-d-tuning \stringTuning <<d, a, d g b e'
                                                                            >
/tmp/gork.ly:13:53: error: syntax error, unexpected end of input
      ("guitar-drop-c-tuning" . "c, g, c f a d'>")))
                                                    
/tmp/gork.ly:1: warning: no \version statement found, please add

\version "2.19.16"

for future compatibility
fatal error: failed files: "/tmp/gork.ly"

Compilation exited abnormally with code 1 at Wed Feb 25 13:13:14

Of course, this also means that the input will be read, parsed, and
tokenized, several times in a row, making this also quite less
efficient.

> Admittedly, we don't have to use such things in the lilypond init
> files; I accept your veto and won't further push into this direction.

It's not just a bad idea in LilyPond's init files.  It is a good
practice to have the syntactical context of input be its location in the
file, without juggling it around between interpreters and input stacks
manually.

Otherwise, error messages cannot properly track the source locations,
and the editor cannot help with formatting and highlighting the source
code appropriately.  And you avoid recombining tokens and several
tokenizers working in sequence on the same input, requiring escaping of
quote characters and other stuff.

-- 
David Kastrup